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Purpose 
This guide provides: 
* Planning and implementation instructions 


* Service overviews 
* Links to detailed information in other service-specific guides. 


Audience 
This guide is designed to help network administrators 


* Understand Open Enterprise Server 2015 SP1 services prior to installing them. 
* Make pre-installation planning decisions. 

* Understand installation options for each platform. 

* Implement the services after they are installed. 


Feedback 


We want to hear your comments and suggestions about this manual and the other documentation 
included with OES 2015 SP1. Please use the User Comments feature at the bottom of each page of 
the online documentation. 


Additional Documentation 


Additional documentation is found on the OES 2015 SP1 Documentation Web site (../../../0es2015). 


Documentation Conventions 


In this documentation, a greater-than symbol (>) is used to separate actions within a step and items 
within a cross-reference path. 


About This Guide 


1.1 


What's New or Changed 


This section summarizes the new and changed features in Novell Open Enterprise Server (OES) 


2015 SP1. 


* 


* 


* 


* 


Section 1.1, “AFP,” on page 15 

Section 1.2, "Archive and Version Services," on page 16 
Section 1.3, “CIFS,” on page 16 

Section 1.4, "Distributed File Services (DFS),” on page 16 
Section 1.5, “DNS and DHCP,” on page 16 

Section 1.6, "Domain Services for Windows," on page 16 
Section 1.7, "Dynamic Storage Technology," on page 16 
Section 1.8, "File Systems and Storage," on page 16 
Section 1.9, "Install," on page 17 

Section 1.10, "iFolder," on page 17 

Section 1.11, "iPrint," on page 17 

Section 1.12, "Linux POSIX Volumes," on page 18 

Section 1.13, "Linux User Management," on page 18 
Section 1.14, "Migration Tool," on page 18 

Section 1.15, "NCP Server," on page 18 

Section 1.16, "NetStorage," on page 18 

Section 1.17, "Novell Cluster Services," on page 18 
Section 1.18, "Novell Identity Translator (NIT)," on page 19 
Section 1.19, "Novell Linux Volume Manager,” on page 19 
Section 1.20, “Novell Remote Manager,” on page 19 
Section 1.21, "Novell Samba," on page 19 

Section 1.22, "Novell Storage Services," on page 19 
Section 1.23, “Novell FTP,” on page 21 

Section 1.24, "Novell Auditing Client Logger (VLOG) Utility," on page 21 
Section 1.25, "QuickFinder," on page 21 

Section 1.26, "Storage Management Services (SMS)," on page 21 
Section 1.27, "Web Services," on page 21 


AFP 


AFP in OES 2015 SP1 has been modified for bug fixes. There are no new features or enhancements 
in OES 2015 SP1. 
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1.2 


1.3 


1.4 


1.5 


1.6 


1.7 


1.8 


Archive and Version Services 


Beginning with OES 2015, Archive and Version Services was discontinued. 


CIFS 


This section describes enhancements and changes in Novell CIFS, beginning with the initial release 
Novell Open Enterprise Server (OES) 2015 SP1. 


Salvage and Purge Support for Active Directory and eDirectory Users 


Beginning with OES 2015 SP1, Active Directory and eDirectory users can perform Salvage or Purge 
operation through NFARM utility. 


For example, Active Directory and eDirectory users can recover or permanently delete the files or 
folders that are already deleted. 


DFS Support 


You can enable or disable DFS support for the CIFS server. By default, this option is disabled. 


Distributed File Services (DFS) 


DFS in OES 2015 SP1 has been modified for bug fixes. There are no new features or enhancements 
in OES 2015 SP1. 


DNS and DHCP 


The DNS/DHCP services in OES 2015 SP1 have been modified for bug fixes. There are no new 
features or enhancements in OES 2015 SP1. 


Domain Services for Windows 


Domain Services for Windows (DSfW) in OES 2015 SP1 has been modified for bug fixes. There are 
no new features or enhancements in OES 2015 SP1. 


Dynamic Storage Technology 


DST in OES 2015 SP1 has been modified for bug fixes. There are no new features or enhancements 
in OES 2015 SP1. 


File Systems and Storage 


Other than bug fixes and the what's new entries mentioned under Novell Storage Services (NSS), 
there are no changes to File Systems and Storage in the OES 2015 SP1 release. 
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1.10 


1.11 


Install 


This section describes enhancements to the installation program for Open Enterprise Server (OES) 
2015 SP1. 

* "Upgrading to OES 2015 SP1” on page 17 

* "Multi-Forest Support for AD Users" on page 17 


Upgrading to OES 2015 SP1 


* Upgrade from OES 11 SP2 to OES 2015 SP1: Channel upgrade allows you to upgrade from 
OES 11 SP2 to OES 2015 SP1 using zypper command. For more information, see Channel 
Upgrade from OES 11 SP2 to OES 2015 SP1 in the OES 2015 SP1: Installation Guide. 


* Upgrade from OES 11 SP3 to OES 2015 SP1: Using zypper command, you can now manually 
upgrade from OES 11 SP3 to OES 2015 SP1. For more information, see Channel Upgrade from 
OES 11 SP3 to OES 2015 SP1 Using Zypper in the OES 2015 SP1: Installation Guide. 


Multi-Forest Support for AD Users 


Multi-forest support allows you to access NSS resources from Active Directory users belonging to AD 
forests having bi-directional trust with OES joined forest or AD domains having bi-directional external 
trust with OES joined forest. 


Forest trust (bi-directional) must be in place and active between the trusting forest and trusted 
forest(s). For more information about NIT, see NIT (Novell Identity Translator) in the OES 2015 SP1: 
NSS AD Administration Guide. 


The following OES components supports the multi-forest changes for AD users: 


* Novell Storage Services (NSS) 

* Common Internet File System (CIFS) 

* Distributed File Services (DFS) 

+ Dynamic Storage Technology (DST) 

* Migration Tool 

* Novell Identity Translator (NIT) 

* Storage Management Services (SMS) 

* OES File Access Rights Management (NFARM) 
* OES User Rights Management (NURM) 

¢ NSS Auditing Client Logger (VLOG) 


¢ NSS Utilities (rights, nssquota, nsschown, and metamig) 


iFolder 


See " What's New in iFolder" in the Novell iFolder 3.9.2 Administration Guide. 


iPrint 


In addition to bug fixes, OES 2015 SP1 provides the following enhancements to Novell iPrint: 
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1.13 


1.14 


1.15 


1.16 


1.17 


iPrint Client 6.05 for Windows 


The iPrint Client is upgraded to version 6.05. This client is available on Windows 10, Windows 8.x, 
Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2012 R2. For more 
information, see Installing the iPrint Client. 


iPrint Client 6.03 for Mac 


The iPrint Client is upgraded to version 6.03. This client is available on Mac 10.11 (El Capitan), OS X 
10.10, OS X 10.9, and OS X 10.8. For more information, see Installing the iPrint Client. 


Novell iPrint Rebranded as Micro Focus iPrint 


Novell is now part of Micro Focus, so the iPrint clients (Windows and Mac) are rebranded as Micro 
Focus iPrint, there is no functionality impact. 


Linux POSIX Volumes 


Linux POSIX volumes in OES 2015 SP1 has been modified for bug fixes. There are no new features 
or enhancements in OES 2015 SP1. 


Linux User Management 


LUM in OES 2015 SP1 has been modified for bug fixes. There are no new features or enhancements 
in OES 2015 SP1. 


Migration Tool 


Migration Tool in OES 2015 SP1 has been modified for bug fixes. There are no new features or 
enhancements in OES 2015 SP1. 


NCP Server 


NCP in OES 2015 SP1 has been modified for bug fixes. There are no new features or enhancements 
in OES 2015 SP1. 


NetStorage 


NetStorage in OES 2015 SP1 has been modified for bug fixes. There are no new features or 
enhancements in OES 2015 SP1. 


Novell Cluster Services 


Cluster Services in OES 2015 SP1 has been modified for bug fixes. There are no new features or 
enhancements in OES 2015 SP1. 
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1.19 


1.20 


1.21 


1.22 


Novell Identity Translator (NIT) 


Multi-Forest Support for AD Users 


Multi-forest support allows you to access NSS resources from Active Directory users belonging to AD 
forests having bi-directional trust with OES joined forest or AD domains having bi-directional external 
trust with OES joined forest. 


Forest trust (bi-directional) must be in place and active between the trusting forest and trusted 
forest(s). For more information about NIT, see NIT (Novell Identity Translator) in the OES 2015 SP1: 
NSS AD Administration Guide. 


The following OES components supports the multi-forest changes for AD users: 
* Novell Storage Services (NSS) 
* Common Internet File System (CIFS) 
¢ Distributed File Services (DFS) 
+ Dynamic Storage Technology (DST) 
* Migration Tool 
* Novell Identity Translator (NIT) 
* Storage Management Services (SMS) 
* OES File Access Rights Management (NFARM) 
* OES User Rights Management (NURM) 
¢ NSS Auditing Client Logger (VLOG) 


¢ NSS Utilities (rights, nssquota, nsschown, and metamig) 


Novell Linux Volume Manager 


NLVM in OES 2015 SP1 has been modified for bug fixes. There are no new features or 
enhancements in OES 2015 SP1. 


Novell Remote Manager 


NRM in OES 2015 SP1 has been modified for bug fixes. There are no new features or enhancements 
in OES 2015 SP1. 


Novell Samba 


Samba in OES 2015 SP1 has been modified for bug fixes. There are no new features or 
enhancements in OES 2015 SP1. 


Novell Storage Services 


NSS provides the following enhancements and changes in OES 2015 SP1: 


* Delayed Block Allocation 


* Trustee Index Media 
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* nsscon (Enhanced) 

* sputil 

* OES User Rights Management (NURM) 

* OES File Access Rights Management (NFARM) 


Delayed Block Allocation 


Improvements in block allocation algorithm leading to reduced disk fragmentation. For more 
information, see Delayed Block Allocation in the OES 2015 SP1: NSS File System Administration 
Guide for Linux. 


Trustee Index Media 


A new media format has been introduced beginning with OES 2015 SP1 to improve the scan time of 
trustee information for NURM, NFARM, and Trusteelnfo.xml. For more information, see Trustee Index 
Media in the OES 2015 SP1: NSS File System Administration Guide for Linux. 


nsscon (Enhanced) 
Commands are added for the following: 


* Update the NSS media for Trustee Index support. For more information on Trustee Index 
commands, see Trustee Index Media in the OES 2015 SP1: NSS File System Administration 
Guide for Linux. 


* Force the Trustee Index support upgrade in a mixed-node cluster using /ForceMedia switch. For 
more information on the /ForceMedia switch, see Trustee Index Media in the OES 2015 SP1: 
NSS File System Administration Guide for Linux. 


* Automatically upgrades the NSS32 and NSS64 pools to latest pool media. For more information, 
see Automatic Pool Media Upgrade Commands in the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 


* Enable or disable the delayed block allocation at the server level. For more information, see 
Delayed Block Allocation Commands in the OES 2015 SP1: NSS File System Administration 
Guide for Linux. 


sputil 


A new administrative tool has been introduced beginning with OES 2015 SP1 for performing purge 
operation on files deleted by eDirectory and AD users. 


For more information, see sputil in the OES 2015 SP1: NSS File System Administration Guide for 
Linux. 


OES User Rights Management (NURM) 
NURM provides the following enhancements and changes in OES 2015 SP1: 
* Contextless login: A new feature has been added to disable the contextless login for eDirectory 
users. 


* Refreshing user maps: If the mappings have changed since the time a user map was created, 
they could be refreshed using the same conditions that were used while creating them. 


* Two way synchronization of rights: Using the user-rights-map utility, rights could be synched 
between Active Directory and eDirectory. 
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1.24 


1.25 


1.26 


1.27 


* Secure LDAP port to connect to the AD server: You can now use SSL to connect securely to 
an AD server. Some of the standard LDAP ports for Active Directory are 389, 636, 3268, and 
3269. 


* Map rights using multiple user maps: You can now select multiple user maps and apply rights 
on the selected volume. 


* Pagination and filtering: When the number of records to be displayed are huge, they are 
paginated, and each page holds up to 1000 records. The filter option works based on records in 
all the pages. 


For more information, see NURM (OES User Rights Management) in the OES 2015 SP1: NSS AD 
Administration Guide. 


OES File Access Rights Management (NFARM) 


Salvage and Purge Support for Active Directory and eDirectory Users: Beginning with OES 
2015 SP1, Active Directory and eDirectory users can perform salvage and purge operation. 
eDirectory users can perform salvage and purge operations through CIFS using NFARM utility 
without AD integration. For more information, see Salvage and Purge in the OES 2015 SP1: NSS AD 
Administration Guide. 


Novell FTP 


FTP Support for AD Users: Beginning with OES 2015 SP1, AD users can leverage the OES FTP 
services and access the NSS resources. For more information, see FTP (Pure-FTPd) and OES 2015 
SP1 for AD Users in the OES 2015 SP1: NSS AD Administration Guide. 


Novell Auditing Client Logger (VLOG) Utility 


In addition to bug fixes, the VLOG utility in OES 2015 SP1 have been enhanced to filter based on 
user names and application names. For more information, see User Element Options and Application 
Element Options in the OES 2015 SP1: NSS Auditing Client Logger (VLOG) Utility Reference. 


QuickFinder 


Beginning with OES 2015, QuickFinder is discontinued. 


Storage Management Services (SMS) 


SMS in OES 2015 SP1 has been modified for bug fixes. There are no new features or enhancements 
in OES 2015 SP1. 


Web Services 


The web services and applications in Novell Open Enterprise Server (OES) 2015 SP1 comprise 
Novell software and open source software that support SUSE Linux Enterprise Server (SLES) 11 
Service Pack 4 (SP4). There are no new features or enhancements in OES 2015 SP1. 
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Welcome to Open Enterprise Server 
2015 SP1 


Updated Network Services 


Open Enterprise Server 


Novell Services 


* AFP * Dynamic Storage Technology * Migration 

* Backup (SMS) * eDirectory * NetStorage 

e CIFS * * Filr (through entitlement) * Client for Open Enterprise Server 
* Clustering (High Availability) *«IFTP* Access / NCP 

* Distributed File Services * iFolder 3.x * Novell Storage Services (NSS) * 
* DNS/DHCP * iPrint * NSS-AD Integration * 

* Domain Services for Windows * iSCSI * SLP 


* Virtualization 
* Enhanced in OES 2015 SP1 


running 
on 


. and Implementation Guide 


SUSE Linux Enterprise Server 


To learn more, click a link in the following table. 


Service More Information about What's Changed 

CIFS CIFS 

FTP Novell FTP 

Novell Storage Services (NSS) Novell Storage Services 

NSS-AD Integration (NIT, NFARM, Novell Identity Translator (NIT), OES User Rights Management 
NURM) (NURM), OES File Access Rights Management (NFARM) 


NSS Active Directory Support Service 


IMPORTANT: To plan, deploy, and administer the NSS AD Support service on your network, refer to 
the instructions and information in the OES 2015 SP1: NSS AD Administration Guide. 
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Integration of NSS and Active Directory 


1. eDirectory user and group access to OES file services on NSS volumes 
is unchanged. 


NCP 


Users and Groups 


NFS 


2. Active Directory users and groups can now be granted 
native Windows (CIFS) and FTP access to NSS volumes. 


NSS Volumes on 
OES 2015 SP1 Servers 


Active Directory 
Users and Groups 


24 Welcome to Open Enterprise Server 2015 SP1 


3.1 


Planning Your OES 2015 SP1 
Implementation 


As you plan which OES services to install, you probably have a number of questions. The following 
sections are designed to help answer your questions and alert you to the steps you should follow for 
a successful OES implementation. 

« Section 3.1, "What Services Are Included in OES 2015 SP1?,” on page 25 

« Section 3.2, "Which Services Do | Need?,” on page 36 

« Section 3.3, "Plan for eDirectory,” on page 36 

« Section 3.4, "Prepare Your Existing eDirectory Tree for OES,” on page 37 

« Section 3.5, "Identify a Purpose for Each Server," on page 38 

« Section 3.6, "Understand Server Requirements," on page 38 

« Section 3.7, "Understand User Restrictions and Linux User Management," on page 38 

« Section 3.8, "Caveats to Consider Before You Install," on page 38 

« Section 3.9, "Consider Coexistence and Migration Issues," on page 51 


¢ Section 3.10, "Understand Your Installation Options," on page 52 


What Services Are Included in OES 2015 SP1? 


This section contains three comparison and information tables to help you understand what OES 
2015 SP1 includes: 


¢ Table 3-1, "Service Comparison—NetWare 6.5 SP8 and OES 2015 SP1,” on page 25 
* Table 3-2, "DES 2015 SP1 Service Changes,” on page 32 
¢ Table 3-3, “OES 2015 SP1 Utility Changes," on page 35 


Table 3-1 Service Comparison—NetWare 6.5 SP8 and OES 2015 SP1 


Service NetWare 6.5 OES 2015 SP1 Platform Differences / Migration Issues 
SP8 
Access Control Lists Yes Yes In combination with NCP Server, Linux supports 


the Novell trustee model for file access on NSS 
volumes and NCP (POSIX) volumes on Linux. 


AFP (Apple File Yes - NFAP Yes - Novell AFP services on NetWare and OES are 
Protocol) AFP proprietary and tightly integrated with eDirectory 
and Novell Storage Services (NSS). 
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NetWare 6.5 
SP8 


Service 


Yes - NetWare 
port of open 
source product 


Apache Web Server 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes - Standard 
Linux 


"Using Apache HTTP Server on OES Servers 
(Single Server or Cluster Nodes)" in the OES 2015 
SP1: Web Services and Applications Guide. 


Administration Instance vs. Public Instance on 
NetWare. 


What's Different about Apache on NetWare. 


Archive and Version Yes 
Services (AVS) (Novell) 


No 


Discontinued from OES 2015. 


Backup (SMS) Yes 


* SMS 
* NSS-Xattr 


Yes 


SMS provides backup applications with a 
framework to develop complete backup and 
restore solutions. For information, see the OES 
2015 SP1: Storage Management Services 
Administration Guide for Linux. 


NSS provides extended attribute handling options 
for NSS on Linux. For information, see “Using 
Extended Attributes (xAttr) Commands" in the 
OES 2015 SP1: NSS File System Administration 
Guide for Linux. 


CIFS (Windows File 
Services) 


Yes - NFAP 


Yes - Novell 
CIFS 


Both NFAP and Novell CIFS are Novell proprietary 
and tightly integrated with eDirectory and Novell 
Storage Services (NSS). 


Clustering Yes 


Yes 


"Comparing Novell Cluster Services for Linux and 
NetWare” in the OES 2015 SP1: Novell Cluster 
Services NetWare to Linux Conversion Guide. 


DFS (Novell Distributed Yes 
File Services) 


Yes 


In combination with NCP Server, DFS supports 
junctions and junction targets for NSS volumes on 
Linux and NetWare. 


DFS also supports junction targets for NCP 
volumes on non-NSS file systems, such as Btrfs, 
Ext3, and XFS. The VLDB command offers 
additional options to manage entries in the VLDB 
for NCP volumes. 


DHCP Yes 


Yes 
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For a comparison between what is available on 
OES and NetWare, see "DHCP Differences 
Between NetWare and OES 2015 SP1” in the 
OES 2015 SP1: Planning and Implementation 
Guide. 


To plan your DHCP implementations, see 
"Planning a DHCP Strategy" in the OES 2015 
SP1: DNS/DHCP Services for Linux 
Administration Guide and “Planning a DHCP 
Strategy” in the NW 6.5 SP8: Novell DNS/DHCP 
Services Administration Guide. 


Service 


DNS 


NetWare 6.5 
SP8 


Yes 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes 


For a comparison between what is available on 
OES and NetWare, see “DNS Differences 
Between NetWare and OES 2015 SP1” in the 
OES 2015 SP1: Planning and Implementation 
Guide. 


See "Planning a DNS Strategy" in the OES 2015 
SP1: DNS/DHCP Services for Linux 
Administration Guide and “Planning a DNS 
Strategy" in the NW 6.5 SP8: Novell DNS/DHCP 
Services Administration Guide. 


Dynamic Storage 
Technology (DST) 


No 


Yes 


For more information, see the OES 2015 SP1: 
Dynamic Storage Technology Administration 
Guide. 


eDirectory 8.8 


Yes 


Yes 


No functional differences. 


eDirectory Certificate 
Server 


Yes 


Yes 


No functional differences. 


eGuide (White Pages) 


Yes 


No 


This functionality is now part of the Identity 
Manager User Application. For more information, 
see the User Application: Administration Guide. 


Filr 


No 


Entitlement 


See “Novell Filr’ on page 30. 


FTP Server 


Health Monitoring 
Services 


Yes 


Yes 


Yes 


Yes 


FTP file services on OES servers are provided by 
Pure-FTPd, a free (BSD), secure, production- 
quality and standard-conformant FTP server. The 
OES implementation includes support for FTP 
gateway functionality as on NetWare and offers a 
level of integration between eDirectory and Pure- 
FTP that allows users to authenticate to eDirectory 
for FTP access to the server. 


For more information, see “Novell FTP (Pure- 
FTPd) and OES 2015 SP1” in the OES 2015 SP1: 
Planning and Implementation Guide. 


In OES, NRM provides health monitoring via the 
open source monitoring tools Ganglia and Nagios. 
These tools do not use SFCB. 


For help with diagnosing problems using Ganglia 
and Nagios in OES, see “Diagnosing Problems 
Using Ganglia and Nagios (OES 2015 SP1)” in the 
OES 2015 SP1: Novell Remote Manager 
Administration Guide. 


The NRM Health Monitor tool is no longer 
available in OES 11 SP2 and later. 


Identity Manager 4.0.2 
Bundled Edition 


No 


Yes 


See “Using the Identity Manager 4.0.2 Bundle 
Edition." (http://www.novell.com/documentation/ 
oes2015/oes implement lx/data/b143d3j6.html). 


iPrint 


Yes 


Yes 


See " Overview" in the OES 2015 SP1: iPrint Linux 
Administration Guide, and "Overview" in the NW 
6.5 SP8: iPrint Administration Guide. 
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Service NetWare 6.5 OES 2015 SP1 Platform Differences / Migration Issues 


SP8 


IPX (Internetwork Yes No 
Packet Exchange) from 
Novell 


No plans to port IPX to OES. 


iSCSI Yes Yes 


The iSCSI target for Linux does not support 
eDirectory access controls like the NetWare target 
does. Nor is the iSCSI initiator or target in OES 
integrated with NetWare Remote Manager 
management. You use YaST management tools 
instead. 


On the other hand, the iSCSI implementation for 
Linux is newer and performs better. 


See Linux-iSCSI Project on the Web (http://linux- 
iscsi.sourceforge.net). 


See "Overview" in the NW 6.5 SP8: iSCSI 1.1.3 
Administration Guide. 


KVM Virtualization No Yes 
Guest 


Of the two OES virtualization solutions (KVM and 
Xen), only Xen is supported for running Netware. 


KVM Virtualization Host No Yes 
Server 


No functional differences. 


LDAP Server for Yes Yes 
eDirectory 


No functional differences. 


Multipath Device Yes Yes 
Management 


NetWare uses NSS multipath I/O. Linux uses 
Device Mapper - Multipath that runs underneath 
other device management services. 


MySQL Yes - NetWare Yes - Standard 
port of open Linux 
source product 


NCP Volumes No Yes 


See MySQL.com on the Web (http:// 
www.mysql.com). 


See “Overview: MySQL” in the NW 6.5 SP8: 
Novell MySQL Administration Guide. 


See also “Configuring MySQL with Novell Cluster 
Services” in the OES 2015 SP1: Web Services 
and Applications Guide. 


NCP Server on Linux supports creating NCP 
volumes on Linux POSIX file systems such as 
btrfs, Reiser, Ext2, Ext3, and XFS. 


OES includes support for much larger NCP 
volumes. 


For information, see “Managing NCP Volumes” in 
the OES 2015 SP1: NCP Server for Linux 
Administration Guide. 


NCP Server Yes Yes 
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NCP services are native to NetWare 6.5 and NSS 
volumes; to have NCP services on OES, the NCP 
Server must be installed. 


See "Benefits of NCP Server" in the OES 2015 
SP1: NCP Server for Linux Administration Guide. 


Service NetWare 6.5 OES 2015 SP1 Platform Differences / Migration Issues 
SP8 

NetStorage Yes Yes NetStorage on Linux offers connectivity to storage 
locations through the CIFS, NCP, and SSH 
protocols. NetWare uses only NCP. 

NetWare Traditional Yes No No plans to port the NetWare Traditional File 

File System System to Linux. 

NetWare Traditional Yes N/A 

Volumes 

NFARM No Yes The Novell Access Rights Management (NFARM) 
shell extension for Windows Explorer lets you 
manage Novell Trustee ACLs for AD users and 
groups who have access to AD-enabled NSS 
volumes. 

For more information, see "Managing the Rights of 
Active Directory Users Using NFARM" in the OES 
2015 SP1: NSS AD Administration Guide. 
NFS Yes - NFAP Yes - native to For NetWare, see "Working with UNIX Machines" 
Linux in the NW 6.5 SP8: AFP, CIFS, and NFS (NFAP) 
Administration Guide. 

NICI (Novell Yes Yes No functional differences. 

International 

Cryptography 

Infrastructure) 

NIT No Yes The Novell Identity Translator provides UID 
support for eDirectory and Active Directory users 
accessing NSS data through CIFS. 

For more information, see "NIT (Novell Identity 
Translator)"in the OES 2015 SP1: NSS AD 
Administration Guide 

NMAS (Novell Modular Yes Yes No functional differences. 

Authentication 

Services) 

Novell Audit Yes No Novell Audit is not included with OES. However, 
the Novell Audit 2.0 Starter pack is available for 
download at no cost on Novell.com (http:// 
www.novell.com/downloads). 

Novell Client for Yes Yes Novell Client connectivity to OES requires that the 

Windows and Linux NCP Server be installed. 

support 
Access to the larger NCP volumes supported by 
OES requires the latest Novell Client software. 

Novell Cluster Services Yes Yes See “Product Features” in the OES 2015 SP1: 


(NCS) 


Novell Cluster Services for Linux Administration 
Guide. 


See “Product Features” in the NW6.5 SP8: Novell 
Cluster Services 1.8.5 Administration Guide. 
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Service 


Novell Filr 


NetWare 6.5 
SP8 


No 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes 


Organizations with a current maintenance 
agreement are entitled to deploy Novell Filr at no 
cost. 


For more information, see the Novell website. 


Filr supports NSS-AD integration in OES 2015 or 
later. 


Novell iFolder 2.x 


Yes 


No 


For migration information, see “Migrating iFolder 
2.x” in the OES 2015 SP1: Migration Tool 
Administration Guide 


Novell iFolder 3.9 


No 


Yes 


OES includes Linux, Macintosh, and Windows 
clients. 


Novell Licensing 
Services 


Yes 


No 


For more information, see “OES Doesn't Support 
NLS" in the OES 2015 SP1: Planning and 
Implementation Guide. 


Novell Linux Volume 


Manager 


No 


Yes 


The Novell Linux Volume Manager (NLVM) 
command line interface can be used to create and 
manage Linux POSIX file systems. 


For information about the syntax and options for 
the NLVM commands used in this section, see the 
OES 2015 SP1: NLVM Reference. 


NSS (Novell Storage 


Services) 


NTPv3 


Yes 


Yes 


Yes 


Yes 


Most NSS services are available on both 
platforms. For a list of NSS features that are not 
used on Linux, see “Cross-Platform Issues for 
NSS" in the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 


In OES 11 and later, NSS supports both the DOS 
and GPT partitioning scheme. 


In OES 11 SP1 and later, NSSMU supports Linux 
volumes in addition to NSS pools and volumes. 


The ntpd. conf file on NetWare can replace an 
OES server's NTP configuration file without 
modification. 


OpenSSH 


Yes 


Yes 


NetWare includes a port of the open source 
product. Linux includes the open source product 
itself. 


See "Functions Unique to the NetWare Platform" 
in the NW 6.5 SP8: OpenSSH Administration 
Guide. 


PAM (Pluggable 
Authentication 
Modules) 


No 


Yes 


PAM is a Linux service that Novell leverages to 
provide eDirectory authentication. eDirectory 
authentication is native on NetWare. 


Pervasive.SQL 


Yes 


No 


Pervasive.SQL is available for Linux from the Web 
(http://www.pervasive.com). 


PKI (Public Key 
Infrastructure) 


Yes 


Yes 
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SP8 

Printing Yes Yes See iPrint. 

QuickFinder Yes No See Search. 

RADIUS Yes Yes See the information on forge.novell.com (http:// 
forge.novell.com/modules/xfmod/project/ 
?edirfreeradius). 

Salvage Yes Yes Salvage is now supported for eDirectory and AD 
users using NFARM utility. 

Samba No Yes Samba is an open source technology available on 
OES. Novell provides automatic configuration for 
authentication through eDirectory. For more 
information, see the OES 2015 SP1: Novell 
Samba Administration Guide. 

Search (QuickFinder) Yes No Discontinued from OES 2015. 

SLP Yes - Novell Yes - For more information, see “SLP” in the OES 2015 

SLP OpenSLP SP1: Planning and Implementation Guide. 


NetWare uses Novell SLP, which provides caching 
of Directory Agent scope information in eDirectory. 
This provides for sharing of scope information 
among DAs. 


OpenSLP on Linux is customized to provide DA 
information retention and sharing as well. 


Software RAIDS (NSS 
volumes) 


Yes (0,1,5,01, Yes (0,1, 5,0 


5 1) 


1,51) 


See "Understanding Software RAID Devices" in 
the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 


Storage Management 
Services (SMS) 


Yes 


Yes 


The SBCON backup engine is not supported on 
Linux. 


The nbackup engine is available for exploring 
SMS capabilities, but in a production environment, 
you should use a third-party, full-featured backup 
engine. 


Beginning with OES 2015, SMS is enhanced to 
support the 64-bit storage enhancements and AD- 
user ACLs on AD-enabled NSS volumes. 


TCP/IP 


Yes 


Yes 


No functional differences. 


Timesync NLM 


Yes 


No 


Timesync will not be ported to Linux. However, 
NTPv3 is available on both Linux and NetWare. 


For more information, see “Time Services” in the 
OES 2015 SP1: Planning and Implementation 
Guide. 
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Service NetWare 6.5 OES 2015 SP1 Platform Differences / Migration Issues 
SP8 

Tomcat Yes Yes NetWare includes Tomcat 4 and a Tomcat 5 
servlet container for iManager 2.7. OES includes 
Tomcat 6. There is no impact to any of the 
administration tools, which are tested and 
supported on both platforms. 
For more information, see "Administration 
Instance vs. Public Instance on NetWare" 

Virtual Office Yes No Virtual Office has been replaced by Novell Vibe A 

(Collaboration) separate purchase is required. For more 
information, see the Novell Vibe website (https:// 
www.novell.com/products/vibe/). 

WAN Traffic Manager Yes No 

Xen Virtualization Yes Yes NetWare 6.5 SP8 (and NetWare 6.5 SP 7) can run 

Guest as a paravirtualized machine. OES can run as a 
paravirtualized machine or fully virtualized 
machine. 

Xen Virtualization Host N/A Yes 


Server 


Table 3-2 OES 2015 SP1 Service Changes 


Service 


Access Control Lists 


OES 2015 SP1 Changes and Information 


* 


You can grant Active Directory users native CIFS access to NSS volumes with 
support for the Novell trustee model. For more information, see "Understanding 
the OES Trustee Model for File System Access" in the OES 2015 SP1: File 
Systems Management Guide. 


AFP (Apple File 
Protocol) 


Unaffected by changes in OES 2015 SP1. Novell AFP is not integrated with 
NSS-AD. 


Apache Web Server 


Apache functionality is unaffected by changes in OES 2015 SP1. 


Archive and Version 
Services (AVS) (Novell) 


Archive and Version Services is discontinued. 


If you need to manage AVS on a pre-OES 2015 server from an OES 2015 or 
later server, the AVS iManager plug-in is available for installation. 


Backup (SMS) 


* SMS 
* NSS-Xattr 


Unaffected by changes in OES 2015 SP1. 


CIFS (Windows File 
Services) 


Beginning with OES 2015 SP1, Active Directory and eDirectory users can 
perform Salvage or Purge operation through NFARM utility. 


CIFS users can access NSS resources in a multi-forest environment. 


novcifs: Lets you enable or disable DFS support for the CIFS server. By default, 
this option is disabled. 


Cluster Services 


Unaffected by changes in OES 2015 SP1. 
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DFS (Novell Distributed * 
File Services) 


Unaffected by changes in OES 2015 SP1. 


Unaffected by changes in OES 2015 SP1. 


Unaffected by changes in OES 2015 SP1. 


DHCP + 
DNS + 
Dynamic Storage * 
Technology (DST) 


For more information, see "What's New or Changed in Dynamic Storage Technology" 


Unaffected by changes in OES 2015 SP1. 


in the OES 2015 SP1: Dynamic Storage Technology Administration Guide. 


Unaffected by changes in OES 2015 SP1. 


eDirectory 8.8 * 
eDirectory Certificate + 
Server 


Unaffected by changes in OES 2015 SP1. 


Filr * 


Filr 2.0 supports the NSS-AD integration service in OES 2015 and later. 


FTP Server * 


Beginning with OES 2015 SP1, FTP server supports NSS AD integration 
service. 


Health Monitoring + 
Services 


Unaffected by changes in OES 2015 SP1. 


Identity Manager 4.0.2 * 
Bundled Edition 


Unaffected by changes in OES 2015 SP1. 


iPrint * 


iPrint doesn't currently support the NSS-AD integration service in OES 2015 
SP1. 


Unaffected by changes in OES 2015 SP1. 


iSCSI * 
KVM Virtualization * 
Guest 


Unaffected by changes in OES 2015 SP1. 


KVM Virtualization Host * 
Server 


Unaffected by changes in OES 2015 SP1. 


LDAP Server for * Unaffected by changes in OES 2015 SP1. 

eDirectory 

Linux User Rights * For LUM to coexist with the Novell ID Translator service, UIDs generated by 

Management LUM must not overlap those generated by NIT. 

Multipath Device * Unaffected by changes in OES 2015 SP1. 

Management 

MySQL * Unaffected by changes in OES 2015 SP1. 

NCP Volumes * Unaffected by changes in OES 2015 SP1. 

NCP Server * Unaffected by changes in OES 2015 SP1. 

NetStorage * NetStorage doesn't currently support the NSS-AD integration service in OES 
2015 SP1. 

NICI (Novell * Unaffected by changes in OES 2015 SP1. 

International 

Cryptography 

Infrastructure) 
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Service 


Novell ID Translator 
(NIT) 


OES 2015 SP1 Changes and Information 


* 


Multi-forest support for AD users. 


NMAS (Novell Modular 
Authentication 
Services) 


Unaffected by changes in OES 2015 SP1. 


Novell Client for 
Windows and Linux 
support 


Unaffected by changes in OES 2015 SP1. 


Novell iFolder 3.9 


iFolder doesn't support the NSS-AD integration service in OES 2015 SP1. 


Novell Linux Volume 
Manager 


Unaffected by changes in OES 2015 SP1. 


NSS (Novell Storage 
Services) 


NSS enhancements in OES 2015 SP1 include the following: 


* 


Delayed Block Allocation: Improvements in block allocation algorithm leading to 


reduced disk fragmentation. 
nsscon utility was enhanced. 


sputil was introduced for performing purge operations on files deleted by 
eDirectory and AD users. 


NTPv3 


Unaffected by changes in OES 2015 SP1. 


PKI (Public Key 


Unaffected by changes in OES 2015 SP1. 


Infrastructure) 

QuickFinder * QuickFinder is discontinued, starting with OES 2015. 
If you need to manage QuickFinder on a pre-OES 2015 server from an OES 
2015 SP1 server, the iManager plug-in is available for installation. 

RADIUS * Unaffected by changes in OES 2015 SP1. 

Salvage * Salvage is now supported for eDirectory and AD users using NFARM utility. 

Samba * Samba cannot run on the same server as Novell CIFS and is unaffected by 
changes in OES 2015 SP1. 

SLP * Unaffected by changes in OES 2015 SP1. 


Software RAIDS (NSS 
volumes) 


Software RAID support is unaffected by the Pool and volume size changes in 
OES 2015 SP1. 


Storage Management 
Services (SMS) 


Unaffected by changes in OES 2015 SP1. 


TCP/IP 


Unaffected by changes in OES 2015 SP1. 


Tomcat 


Unaffected by changes in OES 2015 SP1. 


Xen Virtualization 
Guest 


Xen Virtualization Host 
Server 


Unaffected by changes in OES 2015 SP1. 


Unaffected by changes in OES 2015 SP1. 
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Table 3-3 OES 2015 SP1 Utility Changes 


Utility 


Hard Link Support 


Changes and Information 
Hard link support has changed as follows: 


* All volumes created or migrated to OES 2015 SP1 are automatically hard link 
media upgraded. 


For more information, see Hard Links Commands in the OES 2015 SP1: NSS 
File System Administration Guide for Linux. 


* Because all volumes on OES 2015 SP1 servers are automatically hard-link 
media upgraded, the hard link media upgrade commands 


/ZLSSUpgradeCurrentVolumeMediaFormat 

and 

/ZLSSUpgradeNewVolumeMediaFormat 

have been removed from OES beginning with OES 2015. 


iManager Storage Plug- The following capabilities have been added to the iManager Storage plug-in: 


INS 


* Pool Type: Creating NSS 64-bit pools and volumes and displaying pool type 
information. 


* AD media: Support for creating, upgrading, and enabling pools and volumes to 
support AD users. 


For more information, see Managing NSS Pools in the OES 2015 SP1: NSS File 
System Administration Guide for Linux. 


NFARM 


Beginning with OES 2015 SP1, Active Directory and eDirectory users can perform 
salvage and purge operation. eDirectory users can perform salvage and purge 
operations through CIFS using NFARM utility without AD integration. 


For more information, see Salvage and Purge in the OES 2015 SP1: NSS AD 
Administration Guide. 


nitconfig 


Introduced in OES 2015, nitconfig lets administrators configure the Novell Identity 
Translator (NIT) configuration parameters contained in the nitd.conf file. 


For more information, see nitconfig utility: in the OES 2015 SP1: NSS AD 
Administration Guide. 


novcifs 


You can enable or disable DFS support for the CIFS server. 


[--dfs-supportzyes|no] 


novell-ad-util 


Introduced in OES 2015, novell-ad-util lets administrators join an OES 2015 or later 
server or a Novell cluster resource to an Active Directory domain and manage the 
Kerberos keytabs for the joined components. 


For more information, see Domain Join Tool to Join the OES 2015 Servers to an 
Active Directory Domain in the OES 2015 SP1: NSS AD Administration Guide. 


nsschown 


Options are added for changing file and directory ownership based on the owner's 
Security Identifier (SID) or AD Username. There is also an option to change the 
ownership of extended attributes at the same time. 


nsscon 


Commands are enhanced for this release. 


For more information, see nsscon and NSS Commands in the OES 2015 SP1: NSS 
File System Administration Guide for Linux. 
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Utility Changes and Information 


nssmu The utility is enhanced for this release. 


For more information, see nssmu and NSS Commands in the OES 2015 SP1: NSS 
File System Administration Guide for Linux. 


nssquota Options are added for setting quotas for AD users and groups. 


* -aor --activedirectory 


nsssettings Displays the settings of active NSS pools and volumes. 


For more information, see nsssettings in the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 


NURM Beginning with OES 2015 SP1, NURM provides the following enhancements and 
changes: Contextless login, Refreshing user maps, Two way synchronization of 
rights, Secure LDAP port to connect to the AD server, Map rights using multiple user 
maps, and Pagination and filtering. 


For more information, see NURM (OES User Rights Management) in the OES 2015 
SP1: NSS AD Administration Guide. 


querylog Lets you view recent cluster events. 


This functionality is also available within sbdutil and iManager. 


sbdutil sbdutil lets you manage split-brain support in NCS clusters. 


sputil Introduced in OES 2015 SP1, sputil let administrators perform the purge operation. 


For more information, see sputil in the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 


rights Options are added for managing rights for AD users and groups. 


* -aor --activedirectory 


3.2 Which Services Do I Need? 


We recommend that you review the brief overviews included at the beginning of each service section 
in this guide to get a full picture of the solutions that OES 2015 SP1 offers. It is not uncommon that 
administrators discover capabilities in OES that they didn't know existed. 


33 Plan for eDirectory 


eDirectory is the heart of OES network services and security. 


¢ Section 3.3.1, “Installing Into a New Tree," on page 37 


¢ Section 3.3.2, “Installing Into an Existing Tree," on page 37 
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3.3.1 Installing Into a New Tree 


If you are creating a new eDirectory tree on your network, you must do some additional planning 
before you install the first server into the tree. The first server is important for two reasons: 


* You create the basic eDirectory tree structure during the first installation 


* The first server permanently hosts the Certificate Authority for your organization 
To ensure that your eDirectory tree meets your needs, take time to plan the following: 


* Structure of the eDirectory tree: A well-designed tree provides containers for servers, users, 
printers, etc. It is also optimized for efficient data transfer between geographically dispersed 
locations. For more information, see "Designing Your NetIQ eDirectory Network” in the NetIQ 
eDirectory 8.8 SP8 Administration Guide. 


* Time synchronization: eDirectory requires that all servers, both NetWare and OES, be time 
synchronized. For more information, see Chapter 12.3, "Time Services," on page 100. 


* Partitions and replicas: eDirectory allows the tree to be partitioned for scalability. Replicas 
(copies) of the partitions provide fault tolerance within the tree. The first three servers installed 
into an eDirectory tree automatically receive replicas of the tree's root partition. You might want 
to create additional partitions and replicas. For more information, see "Managing Partitions and 
Replicas" in the NetIQ eDirectory 8.8 SP8 Administration Guide. 


For information on these and other eDirectory planning tasks, see the NetIQ eDirectory 8.8 SP8 
Administration Guide. 


3.3.2 Installing Into an Existing Tree 


When installing into an existing tree, make sure you observe the following best practices whenever 
possible: 


* Use Existing eDirectory Objects: Whenever possible, existing eDirectory objects, 
organizational units, users, groups, password policies, etc. should be used during the 
installation. 

If new contexts or users are needed, it is best to create these prior to the installation. 

* Synchronize Replicas Before and After: Ensure that all eDirectory partitions affected by the 

installation are synchronized before you begin and after you finish the installation. 


Also, before installing into an existing tree, be sure you understand the information in Section 14.2.3, 
"eDirectory Coexistence and Migration," on page 145. 


3.4 Prepare Your Existing eDirectory Tree for OES 


Complete all of the instructions in "Preparing eDirectory for OES 2015 SP1” in the OES 2015 SP1: 
Installation Guide. 


NOTE: If you are installing the first OES server into an existing tree on a NetWare server, you must 
use Deployment Manager (located on the NetWare 6.5 SP8 DVD) to see whether your tree requires 
any updates. 


For instructions on running Deployment Manager, see "Preparing to Install NetWare 6.5 SP8” in the 
NW65 SP8: Installation Guide. 
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3.5 


3.6 


3.7 


3.8 


Identify a Purpose for Each Server 


Large networks usually have one or more servers dedicated to providing a single network service. 
For example, one or more servers might be designated to provide Novell iFolder file services to 
network users while other servers provide iPrint printing services for the same users. 


For smaller organizations, it is often not practical or cost effective to dedicate servers to providing a 
single service. For example, the same server might provide both file and print services to network 
users. 


Prior to installing a new server on your network, you should identify the service or services that it will 
provide and see how it will integrate into your overall network service infrastructure. 


Understand Server Requirements 


OES 2015 SP1 has specific hardware and software requirements. 


Prior to installing OES, make sure your server machine and network environment meet the 
requirements outlined in the following sections: 


* OES 2015 SP1 Server (Physical): "Preparing to Install OES 2015 SP1" in the OES 2015 SP1: 
Installation Guide. 


* OES 2015 SP1 Server (Virtual): "System Requirements" in the OES 2015 SP1: Installation 
Guide. 


Understand User Restrictions and Linux User 
Management 


If you plan to use Linux User Management, be sure you understand the security implications before 
you accept the default PAM-enabled service settings. The implications are explained in 
Section 21.2.2, "User Restrictions: Some OES Limitations," on page 229. 


Caveats to Consider Before You Install 


IMPORTANT: As support packs are released, there are sometimes new caveats identified. Be sure to 
always check the OES Readme (http://www.novell.com/documentation/oes11/oes readme/data/ 
readme.html) for items specific to each support pack. 


This section discusses the following installation/migration caveats: 
« Section 3.8.1, "Adding a Linux Node to a Cluster Ends Adding More NetWare Nodes,” on 
page 39 
¢ Section 3.8.2, "Always Double-Check Service Configurations Before Installing," on page 39 
¢ Section 3.8.3, "Back Button Doesn't Reset Configuration Settings," on page 39 
¢ Section 3.8.4, "Cluster Upgrades Must Be Planned Before Installing OES,” on page 40 
¢ Section 3.8.5, "Common Proxy Password Policy Should Be Assigned,” on page 40 


¢ Section 3.8.6, "Cross-Protocol File Locking Might Need To Be Reconfigured if AFP or CIFS Is 
Functioning on an NCP Server," on page 41 


¢ Section 3.8.7, "Do Not Create Local (POSIX) Users,” on page 41 
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3.8.1 


3.8.2 


3.8.3 


¢ Section 3.8.8, "Do Not Upgrade to eDirectory 8.8 Separately,” on page 41 

* Section 3.8.9, "Follow the Instructions for Your Chosen Platforms," on page 41 

* Section 3.8.10, "If You've Ever Had OES 1 Servers with LUM and NSS Installed," on page 42 
¢ Section 3.8.11, “Novell Identity Translator (NIT),” on page 45 

* Section 3.8.12, "iFolder 3.9.2 Considerations," on page 45 

* Section 3.8.13, "Incompatible TLS Configurations Give No Warning," on page 45 

* Section 3.8.14, "Installing into an Existing eDirectory Tree," on page 45 

* Section 3.8.15, "NetStorage Caveats," on page 46 

* Section 3.8.16, "NetWare Caveats," on page 47 

* Section 3.8.17, "Novell Distributed Print Services Cannot Migrate to Linux," on page 48 
* Section 3.8.18, “NSS Caveats,” on page 48 

* Section 3.8.19, "Plan eDirectory Before You Install," on page 49 

* Section 3.8.20, "Samba Enabling Disables SSH Access," on page 49 

* Section 3.8.21, "Unsupported Service Combinations," on page 49 

* Section 3.8.22, "VNC Install Fails to Set the IP Address in /etc/hosts," on page 51 


Adding a Linux Node to a Cluster Ends Adding More 
NetWare Nodes 


After you add a Linux node to a cluster, you cannot add more NetWare nodes. For more information, 
see the OES 2015 SP1: Novell Cluster Services NetWare to Linux Conversion Guide. 


Always Double-Check Service Configurations Before 
Installing 


It is critical and you double-check your service configurations on the Novell Open Enterprise Server 
Configuration summary page before proceeding with an installation. One reason for this is explained 
in the next section. 


Back Button Doesn't Reset Configuration Settings 


During an installation, after you configure eDirectory and reach the Novell Open Enterprise Server 
Configuration summary screen, service configuration settings have been "seeded" from the 
eDirectory configuration. 


If you discover at that point that something in the eDirectory configuration needs to change, you can 
change the settings by clicking the eDirectory link on the summary page or by clicking the Back 
button. 


In both cases when you return to the summary page, the eDirectory configuration has changed, but 
the individual service configurations have the same eDirectory settings you originally entered. These 
must each be changed manually. 


For example, if you specified the wrong server context while initially configuring eDirectory, the NSS 
and LUM configurations still have the wrong context. You must select each service individually and 
change the server context in them. 
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3.8.5 


Unless you manually change the services affected by changes to eDirectory, your services will at best 
not work as expected and at worst completely fail. 


Cluster Upgrades Must Be Planned Before Installing OES 


Because of differences between Novell Cluster Services on NetWare 6.5 SP8 and OES, there are 
important issues to consider before combining them into a mixed node cluster, as explained in the 
following sections. 

¢ "Service Failover in a Mixed Cluster" on page 40 

¢ “Working with Mixed Node Clusters" on page 40 

+ "Working with NSS-AD Enabled Pools" on page 40 


Service Failover in a Mixed Cluster 


The only cluster-enabled service that can fail over cross-platform (run on either OES 2015 SP1 or 
NetWare 6.5 SP8) is cluster-enabled NSS pools. All other services (iPrint, iFolder, etc.) can only fail 
over between servers that are the same platform. For example, an iPrint service that is running on an 
OES 2015 SP1 server can fail over to another OES 2015 SP1 server in the cluster, but the service 
cannot fail over to a NetWare 6.5 SP8 server. 


Working with Mixed Node Clusters 


See the following sections before working with mixed NetWare and OES clusters: 


* "Planning the Cluster Conversion" and "Planning the Conversion of Load and Unload Scripts" in 
the OES 2015 SP1: Novell Cluster Services NetWare to Linux Conversion Guide. 


"What's New or Changed for Novell Cluster Services" and "Requirements and Guidelines for 
Upgrading Clusters from OES 2 SP3" in the OES 2015 SP1: Novell Cluster Services for Linux 
Administration Guide. 


* 


Working with NSS-AD Enabled Pools 


If you are deploying 64-bit pools or planning to deploy NSS-AD for AD user and group CIFS access to 
NSS, be aware that AD-enabled pools cannot failover to pre-OES 2015 SP1 nodes and will go 
comatose. For more information, see "Upgrading to OES 2015 SP1 and Deploying NSS AD 
(Clustered Environment)" in the OES 2015 SP1: NSS AD Administration Guide. 


Common Proxy Password Policy Should Be Assigned 


When you install a Common Proxy user, it is possible to deselect the Assign Common Proxy 
Password Policy to Proxy User check box. This is not recommended because then the user inherits 
the password policies of the container where it is installed, and that can lead to service failures. 
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3.8.9 


Cross-Protocol File Locking Might Need To Be 
Reconfigured if AFP or CIFS Is Functioning on an NCP 
Server 


Cross-protocol file locking (CPL) default behavior works as follows: 


* All new servers with NCP installed have CPL turned on. 
¢ |f an upgraded server was not configured for CPL prior to the upgrade, CPL will be turned on. 


+ |f an upgraded server was configured for CPL prior to the upgrade, the CPL setting immediately 
preceding the upgrade is retained. 


If a server is only accessed through NCP (AFP and CIFS are not installed), you can achieve an NCP 
performance gain of about 1096 by disabling CPL. However, there is a critical caveat. If you later 
install AFP or CIFS and you forget to re-enable CPL, data corruption can occur. 


There are also obvious implications for clustering. The CPL settings for clustered nodes must match. 


For more information about cross-protocol locking, see "Configuring Cross-Protocol File Locks for 
NCP Server” in the OES 2015 SP1: NCP Server for Linux Administration Guide. 


Do Not Create Local (POSIX) Users 


During the OES 2015 SP1 install you are prompted by the SLES portion of the install to create at least 
one local user besides root, and you are warned if you bypass the prompt. 


Creating local users is not recommended on OES servers because user management in OES is 
managed entirely in eDirectory. The only local user you need on the server is the root user. Creating 
other local users can, in fact, cause unnecessary confusion and result in service-access problems 
that are difficult to troubleshoot. 


eDirectory users are enabled for POSIX access to servers through the Linux User Management 
(LUM) technology installed by default on every OES server. 


Also be aware that not all OES services require that users are LUM-enabled. Novell Client users, for 
example, can access NCP and NSS volumes on OES servers just as they do on NetWare without any 
additional configuration. 


For more information about this topic, see Section 15.2, "Linux User Management: Access to Linux 
for eDirectory Users," on page 153. 


Do Not Upgrade to eDirectory 8.8 Separately 


Do not upgrade to eDirectory 8.8 independently of upgrading to OES 2015 SP1. 


Doing so causes configuration problems that the OES 2015 SP1 install is not designed to handle. 


Follow the Instructions for Your Chosen Platforms 


Although installing Novell services on Linux or NetWare is a straightforward process, the installation 
processes are platform-specific, requiring different sets of media and different installation programs. 
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If You've Ever Had OES 1 Servers with LUM and NSS 
Installed 


Having NSS volumes on OES servers requires certain system-level modifications, most of which are 
automatic. For more information, see Appendix H, "System User and Group Management in OES 
2015 SP1,” on page 257. 


However, as OES has evolved, some initially defined conventions regarding system Users have 
needed adjustment. Be sure to read the information and follow the instructions in this section if your 
network has ever included an OES 1 server with both LUM and NSS installed. 

* "NetStorage, XTier, and Their System Users" on page 42 

* "An NSS Complication" on page 42 

¢ “eDirectory Solves the Basic Problem" on page 42 

+ “ID Mismatches on OES 1" on page 43 

* "The OES 1 Solution: The nssid.sh Script" on page 43 

¢ “OES 2 SP1 or Later Requires a New Approach" on page 43 

* "The Solution: Standardizing the UIDs on all OES servers" on page 43 


NetStorage, XTier, and Their System Users 


By default, certain OES services, such as NetStorage, rely on a background Novell service named 
XTier. 


To run on an OES server, XTier requires two system-created users (named novlxsrvd and 
novlxregd) and one system-created group that the users belong to (named nov1xtier). 


An NSS Complication 


The two system users and their group are created on the local system when XTier is installed. For 
example, they are created when you install NetStorage, and their respective UIDs and GID are used 
to establish ownership of the service's directories and files. 


For NetStorage to run, these XTier users and group must be able to read data on all volume types 
that exist on the OES server. 


As long as the server only has Linux traditional file systems, such as Ext3, Reiser, or XFS, 
NetStorage runs without difficulties. 


However, if the server has NSS volumes, an additional requirement is introduced. NSS data can only 
be accessed by eDirectory users. Consequently, the local XTier users can't access NSS data, and 
NetStorage can't run properly. 


eDirectory Solves the Basic Problem 


Therefore, when NSS volumes are created on the server, the XTier users are moved to eDirectory 
and enabled for Linux User Management (LUM). See Section 15.2, "Linux User Management: 
Access to Linux for eDirectory Users," on page 153. 


After the move to eDirectory, they can function as both eDirectory and POSIX users, and they no 
longer exist on the local system. 
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ID Mismatches on OES 1 


Problems with OES 1 occurred when additional OES NetStorage servers with NSS volumes were 
installed in the same eDirectory container. Because the UIDs and GID were assigned by the Linux 
system, unless the installation process was exactly the same for each OES 1 server, the UIDs and 
GID didn't match server-to-server. 


When the local XTier UIDs and GID on subsequently installed servers didn't match the XTier UIDs 
and GID in eDirectory, NetStorage couldn't access the NSS volumes on the server. 


The OES 1 Solution: The nssid.sh Script 


To solve this problem, the OES 1 installation program looked for XTier ID conflicts, and if the IDs on a 
newly installed server didn't match the IDs in eDirectory, the program generated a script file named 
nssid.sh. The documentation instructed installers to always check for an nssid.sh file on a newly 
installed server, and if the file was found, to run it. The nssid.sh script synchronized all of the XTier 
IDs with those that had already been stored in eDirectory. 


This solution remained viable through the first release of OES 2. 


OES 2 SP1 or Later Requires a New Approach 


IMPORTANT: The following processes described in the next section ("The Solution: Standardizing 
the UIDs on all OES servers") only need to be done once per eDirectory tree. 


Unfortunately, system-level changes in SUSE Linux Enterprise Server 10 SP2 invalidated the 
nssid.sh script solution for OES 2 SP1 and later. Synchronizing the XTier IDs with an OES 1 
installation can cause instability in other non-OES components. Therefore, if you have not already 
done so, you should standardize all XTier IDs on existing servers before installing a new OES 2015 
SP1 server with XTier-dependent services. 


The Solution: Standardizing the UIDs on all OES servers 


If your eDirectory tree has ever contained an OES 1 server with NSS and LUM installed, and if you 
have not already standardized the UIDs for a prior OES 2 SP1 or later release, do the following on 
each server that has NSS and LUM installed: 
1 Log in as root and open a terminal prompt. Then enter the following commands: 
id novlxregd 
id novlxsrvd 


The standardized XTier IDs are UID 81 for novlxregd, UID 82 for novlxsrvd, and GID 81 for 
novlxtier. 


2 (Conditional) If you see the following ID information, the XTier IDs are standardized and you can 
start over with Step 1 for the next server: 


uid=81(novlxregd) gid=81(novlxtier) groups-81(novlxtier) 
uid-82(novlxsrvd) gid=81(novlxtier) groups=81(novlxtier),8(www) 


3 (Conditional) If you see different IDs than those listed above, such as 101, 102, 103, etc., record 
the numbers for both XTier users and the novixtier group, then continue with Step 4. 


You need these numbers to standardize the IDs on the server. 
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4 Download the following script file: 


* 


fix xtier ids.sh (http://www.novell.com/documentation/oes11/scripts/fix xtier ids.sh) 


5 Customize the template file by replacing the variables marked with angle brackets (<>) as 
follows: 


* 


«server name»: The name of the server object in eDirectory. 
This variable is listed on line 38 in the file. Replace it with the server name. 


For example, if the server name is myserver, replace «server name» with myserver so that 
the line in the settings section of the script reads 


server=myserver 
<context>: This is the context of the XTier user and group objects. 


Replace this variable with the fully distinguished name of the context where the objects 
reside. 


For example, if the objects are an Organizational Unit object named servers, replace 
ou=servers,o=company with the fully distinguished name. 


<admin fdn>: The full context of an eDirectory admin user, such as the Tree Admin, who 
has rights to modify the XTier user and group objects. 


Replace this variable with the admin name and context, specified with comma-delimited 
syntax. 


For example, if the tree admin is in an Organization container named company, the full 
context is cn=admin,o=company and the line in the settings section of the script reads 


admin_fdn="cn=admin, o=company" 


<novlxregd_uid>: This is the UID that the system assigned to the local novlxregd user. It 
might or might not be the same on each server, depending on whether the nssid.sh script 
ran successfully. 


Replace this variable with the UID reported for the novlxregd user on this server as listed in 
Step 1 on page 43. 


For example, if the UID for the novlxregd user is 101, change the line to read 
novlxregd_uid=101 


«novlxsrvd uid»: This is the UID that the system assigned to the local novixsrvd user. It 
might or might not be the same on each server, depending on whether the nssid.sh script 
ran successfully. 


Replace this variable with the UID reported for the novlxsrvd user on this server as listed 
when you ran the commands in Step 1 on page 43. 


For example, if the UID for novlxsrvd uid is 102, change the line to read 
novlxsrvd_uid=102 


«novlxtier gid»: This is the GID that the system assigned to the local novlxtier group. It 
might or might not be the same on each server, depending on whether the nssid.sh script 
ran successfully. 


Replace this variable with the GID reported for the novlxtier group on this server as listed 
when you ran the commands in Step 1 on page 43. 


For example, if the GID for novlxtier gid is 101, change the line to read 


novlxtier_gid=101 


6 Make the script executable and then run it on the server. 


IMPORTANT: Changes to the XTier files are not reported on the terminal. 
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3.8.12 


3.8.13 


3.8.14 


Error messages are reported, but you can safely ignore them. The script affects the entire file 
system, and some files are locked because the system is running. 


7 Repeat from Step 1 for each of the other servers in the same context. 


Novell Identity Translator (NIT) 


In OES 2015 SP1, Novell CIFS utilizes a new service that manages the UIDs required for eDirectory 
and Active Directory users on Linux systems. 


Novell Identify Translator works seamlessly with LUM and its configuration requires that its UID range 
not overlap the UID set for LUM. 


For more information, see "NIT (Novell Identity Translator)" in the OES 2015 SP1: NSS AD 
Administration Guide. 


iFolder 3.9.2 Considerations 


For best results, be sure you read and carefully follow the instructions in the Novell iFolder 3.9.2 
Administration Guide and the Novell iFolder 3.9.2 Deployment Guide. This is especially critical if you 
plan to use NSS for your iFolder 3.9.2 data volume. 


Incompatible TLS Configurations Give No Warning 


When you install a new eDirectory tree, the eDirectory Configuration - New or Existing Tree screen 
has the Require TLS for Simple Binds with Password option selected by default. If you keep this 
configuration setting, the eDirectory LDAP server requires that all communications come through the 
secure LDAP port that you specified on the eDirectory Configuration - Local Server Configuration 
screen. By default, this is port 636. 


Unfortunately, the OES install doesn't display a warning if you subsequently configure OES services 
to use non-TLS (non-secure) LDAP communications (port 389). The installation proceeds normally 
but the service configuration fails. 


For example, if you accept the TLS default, then configure Novell DHCP to use non-secure 
communications (by deselecting the Use secure channel for configuration option), the OES install 
doesn't warn that you have created an incompatible configuration. 


After eDirectory and the iManager plug-ins install successfully, the Novell DHCP configuration fails. 
You must then use iManager to change either the LDAP server configuration or the Novell DHCP 
configuration to support your preferred communication protocol. 


Simply enabling non-TLS LDAP communications doesn't disable TLS. It merely adds support for non- 
secure communications with the LDAP server. 


Installing into an Existing eDirectory Tree 


Novell Support has reported a significant number of installation incidents related to eDirectory health 
and time synchronization. To avoid such problems, do the following prior to installing OES: 


* "Consider Coexistence and Migration Issues" on page 46 
* "Do Not Add OES to a Server That Is Already Running eDirectory" on page 46 
* "Be Sure That eDirectory Is Healthy" on page 46 
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* "Be Sure That Network Time Is Synchronized" on page 46 
* "Be Sure that OpenSLP on OES Is Configured Properly" on page 46 


Consider Coexistence and Migration Issues 


If you are installing a new OES 2015 SP1 server into an existing eDirectory tree, be sure to read and 
follow the instructions in "Preparing eDirectory for OES 2015 SP1” in the OES 2015 SP1: Installation 
Guide. 


Do Not Add OES to a Server That Is Already Running eDirectory 


Although you can add OES to an existing SLES 11 server if needed, you cannot install OES on a 
SLES 11 server that is already running eDirectory. 


eDirectory must be installed in conjunction with the installation of OES services. 


Be Sure That eDirectory Is Healthy 


Review and follow the guidelines in "Keeping eDirectory Healthy" in the Net/Q eDirectory 8.8 SP8 
Administration Guide. 


Be Sure That Network Time Is Synchronized 


OES and NetWare 6.5 SP8 servers can receive network time from either an existing eDirectory 
server or from an NTP time source. The critical point is that the entire tree must be synchronized to 
the same time source. For example, do not set your new OES 2015 SP1 server to receive time from 
an NTP source unless the whole tree is synchronized to the same NTP source. 


For an in-depth explanation of OES time synchronization, see Chapter 12.3, "Time Services," on 
page 100. 


Be Sure that OpenSLP on OES Is Configured Properly 


Novell SLP (NetWare) and OpenSLP (Linux) can coexist, but there are differences between the 
services that you should understand before deciding which to use or before changing your existing 
SLP service configuration. For more information, see Section 12.5, “SLP,” on page 112. 


NetStorage Caveats 


* "NetStorage Access to a Cluster Resource Fails When the Resource Comes Online from a 
Comatose State" on page 47 


* "Unable to Use a Common Proxy if ZENworks and NetStorage Are Installed on the Same 
System" on page 47 


* "Common Proxy Password Cannot Exceed 20 Characters" on page 47 


* "NetStorage Purge and Salvage Options Do Not Work on Macintosh with Safari 4.0.x" on 
page 47 
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NetStorage Access to a Cluster Resource Fails When the Resource 
Comes Online from a Comatose State 


To restore access to the storage object, restart the novell-xsrvd process by running the following 
command: 


/etc/init.d/novell-xsrvd restart 


Unable to Use a Common Proxy if ZENworks and NetStorage Are 
Installed on the Same System 


If you are using ZENworks along with NetStorage on the same OES server, you must not use a 
common proxy user. 


Common Proxy Password Cannot Exceed 20 Characters 


If a common proxy user used by NetStorage is assigned a password policy, you must ensure that the 
password size specified in the policy does not exceed 20 characters. 


NetStorage Purge and Salvage Options Do Not Work on Macintosh 
with Safari 4.0.x 


If you are using Safari 4.0.x with Macintosh, the Salvage and Purge options do not work. 


NetWare Caveats 


* "NetWare Licenses and OES Trees" on page 47 
* "NetWare 6.5 Servers Must Be Running SP8" on page 48 


NetWare Licenses and OES Trees 


OES doesn't use Novell Licensing Services (Section 4.6, "Licensing," on page 58). As a result, OES 
servers don't need a license container in eDirectory as part of the server installation. 


In a mixed OES and NetWare eDirectory tree, at least one NetWare server must hold a replica for 
each partition where there is a NetWare server object. Without this configuration, It is impossible to 
install licenses or to service requests from NetWare servers to consume those licenses. 


If you need to install a NetWare server in an OES tree, you must do the following after installing the 
first NetWare server in a partition: 
1 Install iManager on the NetWare server, or use iManager Workstation. 


You can do this during initial installation or later as described in "Installing iManager” in the NetIQ 
iManager Installation Guide. 


2 Add a Read/Write replica to the server as described in “Adding a Replica" in the NetIQ 
eDirectory 8.8 SP8 Administration Guide. 
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3 Install the NetWare license as described in "Installing and Removing License Certificates" in the 
NW 6.5 SP8: Licensing Services Administration Guide. 


The iManager Licensing plug-in is not installed on OES servers. If you have configured Role- 
Based Services, you need to make sure the licensing plug-in is installed and added to the RBS 
collection. For more information, see "Upgrading iManager” in the NetIQ iManager Installation 
Guide. 


NetWare 6.5 Servers Must Be Running SP8 


If you are installing OES servers into a tree containing NetWare 6.5 servers, be sure that the following 
server types have been updated to SP8 prior to installing OES: 


* SLP Directory Agents: If the SLP Directory Agents on your network are not running NetWare 
6.5 SP8, installing an OES server into the tree can cause the DA servers to abend. 


* LDAP Servers: If the LDAP servers referenced in your installation are not running NetWare 6.5 
SP8, the servers might abend during a schema extension operation. 


Novell Distributed Print Services Cannot Migrate to Linux 


NDPS clients are not supported on OES. You must therefore migrate any NDPS clients to iPrint 
before you migrate your print services to OES. For more information, see "Migrating NDPS Printers to 
iPrint" in the NW 6.5 SP8: iPrint Administration Guide. 


NSS Caveats 


* "About New Media Support and Clusters" on page 48 
* "Removable Media Cannot Be Mounted on OES" on page 48 


About New Media Support and Clusters 


The new media support for hard links on OES NSS volumes was not available for OES 1 SP2 Linux 
and earlier, but it was available for NetWare 6.5 SPA and later. 


If you've already upgraded the media format of the volume, you cannot fail over to a node that is 
running OES 1 SP2 until you have upgraded the node to a later version of OES. 


Removable Media Cannot Be Mounted on OES 


CD and DVD media and image files cannot be mounted as NSS volumes on OES; instead, they are 
mounted as Linux POSIX file systems. 


For more details about NSS compatibility, see “Cross-Platform Issues for NSS Volumes" in the OES 
2015 SP1: NSS File System Administration Guide for Linux. 
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3.8.19 Plan eDirectory Before You Install 


3.8.20 


3.8.21 


Although the default eDirectory settings work for simple trees, they are not usually practical for a 
production implementation. For example, by default the tree Admin user and the server are installed 


in the same context. 


Some administrators, when they discover that the tree structure doesn't meet their needs, assume 
they can rectify the situation by uninstalling and then reinstalling eDirectory. This simply cannot be 


done. 


In fact, OES services cannot be uninstalled. For more information, see "Disabling OES 2015 


Services" in the OES 2015 SP1: Installation Guide. 


Samba Enabling Disables SSH Access 


Enabling users for Samba automatically disables SSH access for them. However, this default 
configuration can be changed. For more information, see Section 11.4, “SSH Services on OES 2015 


SP1," on page 92. 


Unsupported Service Combinations 


Do not install any of the following service combinations on the same server. Although not all of the 
combinations shown in Table 3-4 cause pattern conflict warnings, Novell does not support any of 


them. 


Table 3-4 Unsupported Service Combinations 


Service 


Novell AFP 


Unsupported on the Same Server 


File Server (Samba) 

Netatalk 

Novell Domain Services for Windows 
Novell Samba 


Xen Virtual Machine Host Server 


Novell Backup / Storage Management Services 


Novell CIFS 


No restrictions 


File Server (Samba) 
Novell Domain Services for Windows 
Novell Samba 


Xen Virtual Machine Host Server 


Novell Cluster Services (NCS) 


Novell DHCP 


High Availability 
Novell Domain Services for Windows 


DSfW can actually be installed and run on the 
same server as NCS, but DSfW cannot run as a 
clustered service. 


Xen Virtual Machine Host Server 


Novell DNS 


Xen Virtual Machine Host Server 
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Service Unsupported on the Same Server 


Novell Domain Services for Windows * File Server (Samba) 
* Novell AFP 
* Novell CIFS 
* Novell Cluster Services (NCS) 


NCS can actually be installed and run on the 
server, but DSfW cannot run as a clustered 
service. 


* Novell FTP 

* Novell iFolder 

* Novell NetStorage 

* Novell Pre-Migration Server 
* Novell Samba 


* Xen Virtual Machine Host Server 


NetlQ eDirectory * Directory Server (LDAP) 


* Xen Virtual Machine Host Server 


Novell FTP * Novell Domain Services for Windows 


* Xen Virtual Machine Host Server 


Novell iFolder * Novell Domain Services for Windows 


* Xen Virtual Machine Host Server 


Novell iManager * Xen Virtual Machine Host Server 


Novell iPrint * Print Server (CUPS) 
CUPS components are actually installed, but 
CUPS printing is disabled. For more 
information, see Section 6.8.6, "iPrint Disables 
CUPS Printing on the OES Server," on 
page 70. 


* Xen Virtual Machine Host Server 


Novell Linux User Management (LUM) No restrictions 
Novell NCP Server / Dynamic Storage Technology * Xen Virtual Machine Host Server 
Novell NetStorage * Novell Domain Services for Windows 


* Xen Virtual Machine Host Server 


Novell Pre-Migration Server * Novell Domain Services for Windows 


* Xen Virtual Machine Host Server 


Novell Remote Manager (NRM) * Xen Virtual Machine Host Server 
Novell Samba * File Server (Samba) 
* Novell CIFS 


* Novell Domain Services for Windows 


* Xen Virtual Machine Host Server 
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3.8.22 


3.9 


Service 


Novell Storage Services (NSS) 


Unsupported on the Same Server 


* 


Xen Virtual Machine Host Server 


Novell Storage Services AD Support 


* 


* 


File Server (Samba) 
Novell Domain Services for Windows 
Novell Samba 


Xen Virtual Machine Host Server 


Xen Virtual Machine Host Server 


File Server (Samba) 
Novell AFP 

Novell CIFS 

Novell DHCP 
Novell DNS 

Novell Domain Services for Windows 
NetlQ eDirectory 
Novell FTP 

Novell iFolder 
Novell iManager 
Novell iPrint 


Novell NCP Server / Dynamic Storage 
Technology 


Novell NetStorage 

Novell Pre-Migration Server 
Novell Remote Manager (NRM) 
Novell Samba 

Novell Storage Services 


Print Server (CUPS) 


VNC Install Fails to Set the IP Address in /etc/hosts 


If you install through a VNC connection, the /etc/hosts file is configured with a loop back address 


assigned to the hostname. This can cause problems with services. 


Using a text editor, modify /etc/hosts so that the hostname is associated with its actual IP address. 


Consider Coexistence and Migration Issues 


You probably have a network that is already providing services to network users. In many cases, the 
services you are currently running will influence your approach to implementing OES. In some cases, 


there are specific paths to follow so that the OES integration process is as smooth as possible. 


Novell has invested considerable effort in identifying service coexistence and migration issues you 


might face. We understand, however, that we can't anticipate every combination of services that you 


might have. Therefore, we intend to continue developing coexistence and migration information. 
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For information about coexistence of OES 2015 SP1 servers with existing NetWare and Linux 
networks, see Chapter 8, "Migrating Existing Servers and Data," on page 81. 


3.10 Understand Your Installation Options 


Before installing OES, you should be aware of the information in the following sections: 


¢ Section 3.10.1, “OES 2015 SP1 Installation Overview,” on page 52 
¢ Section 3.10.2, "About Your Installation Options," on page 53 
¢ Section 3.10.3, "Use Predefined Server Types (Patterns) When Possible," on page 54 


3.10.1 OES 2015 SP1 Installation Overview 


The software and network preparation processes required to install OES 2015 SP1 are outlined in 
Figure 3-1. 


NOTE: Chapter 4, "Getting and Preparing OES 2015 SP1 Software," on page 55 contains 
instructions for obtaining the ISO image files referred to in the following illustration. 
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3.10.2 


Figure 3-1 OES 2015 SP1 Install Preparation 
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For detailed instructions, see “Setting Up a Network Installation Source” in the OES 2015 SP1: 


Installation Guide. 


For information about preparing the tree, see “NetIQ eDirectory Rights Needed for Installing OES” 
and “Preparing eDirectory for OES 2015 SP1” in the OES 2015 SP1: Installation Guide. 


About Your Installation Options 


As illustrated in the previous section, OES 2015 SP1 lets you install from either physical media or 


from files on the network. 


¢ “OES 2015 SP1 Options" on page 54 


¢ “Virtual Machine Installation Options” on page 54 
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3.10.3 


OES 2015 SP1 Options 


OES 2015 SP1 includes numerous installation options as documented in the OES 2015 SP1: 
Installation Guide. 


* Integrated Media Install: You can install SLES 11 SP4 and OES 2015 SP1 from a single ISO or 
DVD obtained from a Novell Authorized Reseller or created from a downloaded ISO image file. 


See "Preparing Physical Media for a New Server Installation or an Upgrade " in the OES 2015 
SP1: Installation Guide. 


* CDIDVD Install: You can install SLES 11 SP4 by using a DVD and then install OES 2015 SP1 
from a CD, both of which can be either obtained from a Novell Authorized Reseller or created 
from downloaded ISO image files. 


See "Preparing Physical Media for a New Server Installation or an Upgrade " in the OES 2015 
SP1: Installation Guide. 


* Network Install: You can install from the network by using the NFS, FTP, or HTTP protocol. 


If you are installing from both SLES and OES media, using the network saves you from 
swapping media on the server during the installation. 


See "Setting Up a Network Installation Source" in the OES 2015 SP1: Installation Guide. 


Automated Install: You can install from the network by using an Auto YaST file. 


* 


This lets you install without providing input during the installation process. It is especially useful 
for installing multiple servers with similar configurations. 


See "Using AutoYaST to Install and Configure Multiple OES Servers" in the OES 2015 SP1: 
Installation Guide. 


Virtual Machine Installation Options 
Virtual machine installations offer additional options. For more information, see 


* "Installing, Upgrading, or Updating OES on a VM” in the OES 2015 SP1: Installation Guide 
¢ “Installing and Managing NetWare on a Xen-based VM” in the OES 2015 SP1: Installation Guide 


Use Predefined Server Types (Patterns) When Possible 


OES 2015 SP1 includes predefined server installation options that install only the components 
required to provide a specific set of network services. These server types are called patterns. 


For example, if you want to install an OES 2015 SP1 server that provides enterprise level print 
services, you should select the Novell iPrint Server pattern during the installation. 


You should always choose a predefined server type if one fits the intended purpose of your server. If 
not, you can choose to install a customized OES 2015 SP1 server with only the service components 
you need. 


More information about server patterns is available in " DES Services Pattern Descriptions" in the 
OES 2015 SP1: Installation Guide. 
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4.1 


4.2 


4.3 


Getting and Preparing OES 2015 SP1 
Software 


This section contains instructions for getting and preparing Open Enterprise Server 2015 or later 
software and discusses the following topics: 


* Section 4.1, "Do You Have Upgrade Protection?,” on page 55 

¢ Section 4.2, “64-Bit Only,” on page 55 

¢ Section 4.3, "Do You Want to Purchase OES 2015 SP1 or Evaluate It?," on page 55 
¢ Section 4.4, “Evaluating OES 2015 SP1 Software,” on page 56 

¢ Section 4.5, "Downloading and Preparing OES Software,” on page 57 


* Section 4.6, "Licensing," on page 58 


If you have not already done so, we recommend that you review the information in Section 3.10, 
"Understand Your Installation Options," on page 52. 


Do You Have Upgrade Protection? 


If you have Novell Upgrade Protection, you can upgrade to OES 2015 SP1 and the associated 
support packs, free of charge until your upgrade protection expires. After your protection expires, the 
OES 2015 SP1 upgrade link disappears from your account page. 


For more information and to start the upgrade process, do the following: 


1 Using your Novell account information, log in to the Novell Web Site (https://secure- 
www.novell.com/center/regadmin/jsps/home app.jsp). 


2 Follow the instructions on the page to obtain the upgrade to Open Enterprise Server 2015 or 
later. 


64-Bit Only 


Compatibility is the first thing to consider as you start planning which software to download and install. 


OES 2015 SP1 is a set of services or an "add-on product" that runs on SUSE Linux Enterprise Server 
(SLES 11 SP4) and is available in 64-bit only. 


Do You Want to Purchase OES 2015 SP1 or 
Evaluate It? 


If you want to evaluate OES prior to purchasing it, skip to the next section, Evaluating OES 2015 SP1 
Software. 


If you have decided to purchase OES 2015 SP1, visit the Novell How to Buy OES 2015 SP1 Web 
page (http://www.novell.com/products/openenterpriseserver/howtobuy.html). 
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4.4 


4.4.1 


4.4.2 


4.4.3 


When you purchase OES 2015 SP1, you receive two activation codes for OES 2015 SP1 (one for 
OES 2015 SP1 services and one for SUSE Linux Enterprise Server 11). Both codes are required for 
registering an OES 2015 SP1 system in the Novell Customer Center. After it is registered, your server 
can receive online updates, including the latest support pack. 


As part of the purchase process, it is important that you understand the OES 2015 SP1 licensing 
model. For a brief description, see Section 4.6, "Licensing," on page 58. 


After completing your purchase, the installation process goes more smoothly if you understand your 
installation options. If you haven't already done so, be sure to review the information in Section 3.10, 
"Understand Your Installation Options," on page 52 and then skip to Chapter 5, "Installing OES 2015 
SP1," on page 61. 


Evaluating OES 2015 SP1 Software 


This section walks you through the OES 2015 SP1 software evaluation process and discusses the 
following topics: 


¢ Section 4.4.1, “Understanding OES 2015 SP1 Software Evaluation Basics,” on page 56 


¢ Section 4.4.2, "Evaluating OES 2015 SP1,” on page 56 
¢ Section 4.4.3, “Installing OES 2015 SP1 for Evaluation Purposes,” on page 56 


Understanding OES 2015 SP1 Software Evaluation Basics 


You can evaluate the full OES 2015 SP1 product. The evaluation software is the complete, fully 
functional OES 2015 SP1 product. 


As you install each server, you are required to accept an end user license agreement (EULA). Your 
rights to evaluate and use the OES 2015 SP1 product are limited to the rights set forth in the EULA. 


Briefly, the evaluation period for OES 2015 SP1 servers is 60 days. To receive software updates 
during this time, you must have or create an account with the Customer Center, receive evaluation 
codes for OES 2015 SP1 and SLES 11 while downloading the software, and use these codes to 
register your server. No software updates can be downloaded after the 60-day evaluation period 
expires until you purchase the product. 


Evaluating OES 2015 SP1 


During the evaluation period, we recommend that you fully explore the many services available in 
OES 2015 SP1. 


Installing OES 2015 SP1 for Evaluation Purposes 


After completing the instructions in Section 4.5.1, "Downloading OES 2015 SP1 Software from the 
Novell Web Site," on page 57, you will have two activation/evaluation codes: one for OES 2015 SP1 
and another for SLES 11. As you install OES 2015 SP1, you should register with the Novell Customer 
Center and use these codes to enable your server for online updates from the OES 2015 SP1 and 
SLES 11 patch channels. 


IMPORTANT: Always download the current patches during an installation. 
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4.5 


4.5.1 


Instructions for using the activation codes during an installation are found in "Specifying Novell 
Customer Center Configuration Settings" in the OES 2015 SP1: Installation Guide. 


The evaluation period begins when the codes are issued. Use the same activation codes for each 
OES 2015 SP1 server you install during the evaluation period. 


Downloading and Preparing OES Software 


* Section 4.5.1, "Downloading OES 2015 SP1 Software from the Novell Web Site," on page 57 
* Section 4.5.2, "Preparing the Installation Media," on page 58 


* Section 4.5.3, "Installing Purchased Activation Codes after the Evaluation Period Expires," on 
page 58 


Downloading OES 2015 SP1 Software from the Novell Web 
Site 

If you already have OES 2015 SP1 ISO image files, skip to Section 4.5.2, "Preparing the Installation 
Media," on page 58. 


If you have OES 2015 SP1 product media (CDs and DVDs), skip to Section 4.4.3, "Installing OES 
2015 SP1 for Evaluation Purposes," on page 56. 


To download ISO image files from the Web: 
1 If you don't already have a Novell account, register for one on the Web (https://secure- 
www.novell.com/selfreg/jsp/createAccount.jsp?). 
Access the Novell Downloads Web page (http://download.novell.com). 
Do a keyword search for Open Enterprise Server 2015 SP1. 
Click the proceed to download button (upper right corner of the first table). 


cT fF WwW N 


If you are prompted to log in, type your Novell Account » username and password, then click 
login. 


6 Accept the Export Agreement (required for first downloads only) and answer the survey 
questions about your download (optional). 


7 Print the download page. You need the listed MD5 verification numbers to verify your downloads. 
8 Scroll down to the Download Instructions section and click the Download Instructions link. 
9 Print the Download Instructions page for future reference. 


10 Use the information on the Download Instructions page to decide which files you need to 
download for the platforms you plan to evaluate, then mark them on the MD5 verification list on 
the page you printed in Step 7. 


11 On the download page, start downloading the files you need by clicking the download button for 
each file. 


12 If you have purchased OES 2015 SP1 previously and received your OES 2015 SP1 and SLES 
11 activation codes, skip to Step 15. 


Otherwise, in the Evaluating Open Enterprise Server 2015 SP1 section, click the Get Activation 
Codes link in the Novell Open Enterprise Server 2015 SP1 paragraph. 


60-day evaluation codes are sent in separate e-mail messages to the e-mail address associated 
with your Novell account. 


13 Access your e-mail account and print the messages or write down the activation codes. 
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4.5.2 


4.5.3 


58 


4.6 


Both the OES 2015 SP1 and the SLES 11 codes are required for product registration and 
downloading software updates. 


14 Click Back to return to the download page. 


15 In the download table at the top of the page, click the Install Instructions > View link at the end of 
the list of files to download. 


Although you might have printed this file earlier, the online version is required for the steps that 
follow. 


16 Scroll past the download decision tables; while you wait for the downloads, read through the brief 
installation instructions, clicking the links for more information. 


17 Verify the integrity of each downloaded file by running an MD5-based checksum utility on it and 
comparing the values against the list you printed in Step 15. 


For example, on a Linux system you can enter the following command: 
md5sum filename 
where filename is the name of the .iso file you are verifying. 


For a Windows system, you need to obtain a Windows-compatible MD5-based checksum utility 
from the Web and follow its usage instructions. 


18 (Optional) If you plan to install OES 2015 SP1 from files on your network, see the instructions in 
"Setting Up a Network Installation Source" in the OES 2015 SP1: Installation Guide. 


Preparing the Installation Media 


IMPORTANT: If you have downloaded .iso image files from the Web, it is critical that you verify the 
integrity of each file as explained in Step 17 on page 58. Failure to verify file integrity can result in 
failed installations, especially in errors that report missing files. 


Instructions for preparing installation media are located in "Setting Up a Network Installation Source" 
in the OES 2015 SP1: Installation Guide. 


Installing Purchased Activation Codes after the Evaluation 
Period Expires 


After purchasing Open Enterprise Server, use the instructions in "Registering the Server in the Novell 
Customer Center Using the Command Line" in the OES 2015 SP1: Installation Guide to enter the 
purchased activation codes that you received with your purchase. After logging in as root, complete 


the step where you enter the activation codes, replacing the evaluation codes with the purchased 
codes. 


Licensing 


This section explains the following: 


¢ Section 4.6.1, “The OES 2015 SP1 Licensing Model,” on page 59 
¢ Section 4.6.2, "DES Doesn't Support NLS,” on page 59 
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4.6.1 


4.6.2 


The OES 2015 SP1 Licensing Model 


The only OES 2015 SP1 licensing restriction is the number of user connections allowed to use OES 
2015 SP1 services on your network. You are authorized to install as many OES 2015 SP1 servers as 
you need to provide OES 2015 SP1 services to those users. 


For example, if your OES 2015 SP1 license is for 100 user connections, you can install as many OES 
2015 SP1 servers as desired. Up to 100 users can then connect to and use the services provided by 
those OES 2015 SP1 servers. When you install OES 2015 SP1, you must accept an end user license 
agreement (EULA). Your rights to use the OES 2015 SP1 product are limited to the rights set forth in 
the EULA. Violators of the Novell license agreements and intellectual property are prosecuted to the 
fullest extent of the law. 


To report piracy and infringement violations, please call 1-800-PIRATES (800-747-2837) or send e- 
mail to pirates@novell.com. 


For more information on OES licensing, see the Novell Licensing EULA page on the Novell Web site 
(http:/Awww.novell.com/licensing/eula/). 


OES Doesn't Support NLS 


Novell Licensing Services (NLS) are not available on OES, nor does an OES installation require a 
license/key file pair (*. n1f and *.nfk). Therefore, in a mixed OES and NetWare eDirectory tree, at 
least one NetWare server must hold a replica for each partition where there is a NetWare server 
object. For more information about licensing for NetWare servers in OES trees, see “NetWare 
Licenses and OES Trees” on page 47. 
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5.1 


5.1.1 


Installing OES 2015 SP1 


IMPORTANT: Before you install Open Enterprise Server 2015 SP1, be sure to review the information 
in Chapter 3, “Planning Your OES 2015 SP1 Implementation,” on page 25, especially Section 3.8, 
“Caveats to Consider Before You Install,” on page 38. 


This section briefly covers the following: 


¢ Section 5.1, “Installing OES 2015 SP1 on Physical Servers,” on page 61 
¢ Section 5.2, “Installing OES 2015 SP1 Servers in a Xen VM,” on page 62 
¢ Section 5.3, “Installing OES 2015 SP1 Servers in a KVM Virtual Machine," on page 62 


Installing OES 2015 SP1 on Physical Servers 


The OES 2015 SP1 installation leverages the SUSE Linux YaST graphical user interface. You can 
install OES 2015 SP1 services on an existing SUSE Linux Enterprise Server 11 SP4 server, or you 
can install both OES 2015 SP1 and SLES 11 SP4 at the same time, making installation a seamless 
process. 


To ensure a successful installation: 


1. Read and follow all instructions in the OES 2015 SP1: Readme. 


2. Carefully follow the instructions in the OES 2015 SP1: Installation Guide, especially those found 
in 


* "Preparing to Install OES 2015 SP1” 
* "Installing OES 2015 SP1 as a New Installation" 


3. Make sure you always download the latest patches as part of the Customer Center configuration 
during the install. This ensures the most stable configuration and installation process and 
prevents some issues that are documented in the product Readme. 


4. After updating the server, you are prompted for the root password. 


This happens because the server reboots as part of the update process and the root password 
is no longer in memory. 


5. During the installation, you have the option to disable each service for later configuration. 
However, we recommend that you configure all services at install time simply because the 
process is more streamlined. 


For more information on configuring services later, see "Installing or Configuring OES 2015 SP1 
on an Existing Server" in the OES 2015 SP1: Installation Guide. 


What's Next 


After installing OES 2015 SP1 and before starting to use your new server, be sure to review the 
information in Chapter 6, "Caveats for Implementing OES 2015 SP1 Services," on page 63. 


The various service sections in this guide contain information about completing your OES 2015 SP1 
services implementation. See the sections for the services you have installed, beginning with 
Chapter 11, "Managing OES 2015 SP1,” on page 89. 
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5.2 Installing OES 2015 SP1 Servers in a Xen VM 


Installing OES 2015 SP1 servers on a Xen virtual machine involves installing an OES 2015 SP1 or 
SUSE Linux Enterprise Server (SLES) 11 SP4 VM host server, creating a VM, and then installing a 
NetWare or OES server in the VM. 


To get started with Xen virtualization in OES 2015 SP1, see the following: 


* "Introduction to Xen Virtualization (http://www.suse.com/documentation/sles11/book xen/data/ 
cha xen basics.html)" in the Virtualization with Xen (http://www.suse.com/documentation/ 
sles11/book xen/data/book xen.html)guide. 


* “Installing OES as a VM Host Server” in the OES 2015 SP1: Installation Guide. 
¢ “Installing, Upgrading, or Updating OES on a VM" in the OES 2015 SP1: Installation Guide. 


“Installing and Managing NetWare on a Xen-based VM” in the OES 2015 SP1: Installation 
Guide. 


* 


5.33 Installing OES 2015 SP1 Servers in a KVM Virtual 
Machine 


Installing OES 2015 SP1 servers on a KVM virtual machine involves installing an OES 2015 SP1 or 


SUSE Linux Enterprise Server (SLES) 11 SP4 VM host server, creating a VM, and then installing an 
OES server in the VM. 


To get started with KVM virtualization in OES 2015 SP1, see the following: 


¢ The Virtualization with KVM (http://www.suse.com/documentation/sles11/book kvm/data/ 
book kvm.html)guide. 
* “Installing OES as a VM Host Server” in the OES 2015 SP1: Installation Guide. 


¢ “Installing, Upgrading, or Updating OES on a VM" in the OES 2015 SP1: Installation Guide. 
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Caveats for Implementing OES 2015 SP1 
Services 


This section presents a few pointers for avoiding common Open Enterprise Server 2015 SP1 
implementation problems. 


The list that follows is not comprehensive. Rather, it simply outlines some of the more common 
problems reported by network administrators. To ensure successful service implementations, you 
should always follow the instructions in the documentation for the services you are implementing. 

* Section 6.1, “AFP,” on page 64 

¢ Section 6.2, "Avoiding POSIX and eDirectory Duplications,” on page 64 

¢ Section 6.3, “CIFS,” on page 66 

+ Section 6.4, "CUPS on OES,” on page 67 

¢ Section 6.5, “DSfW: MMC Password Management Limitation," on page 67 

¢ Section 6.6, “eDirectory,” on page 67 

¢ Section 6.7, "iFolder 3.9.2,” on page 69 

¢ Section 6.8, “iPrint,” on page 69 

¢ Section 6.9, "LDAP—Preventing “Bad XML” Errors," on page 70 

¢ Section 6.10, “LUM Cache Refresh No Longer Persistent,” on page 71 

¢ Section 6.11, “Management,” on page 71 

¢ Section 6.12, "McAfee Antivirus Requires Additional Configuration," on page 73 

¢ Section 6.13, “NCP,” on page 73 

¢ Section 6.14, “Novell Identity Translator (NIT),” on page 74 

¢ Section 6.15, “Novell-tomcat Is for OES Use Only,” on page 75 

¢ Section 6.16, “NSS,” on page 75 

¢ Section 6.17, “OpenLDAP on OES,” on page 75 

¢ Section 6.18, “Samba,” on page 76 

¢ Section 6.19, “SLP Registrations Are Not Retrieved from a Novell SLP DA,” on page 76 


¢ Section 6.20, “Synchronizing NMAS Login Methods Is Required to Avoid Login Failures,” on 
page 76 


¢ Section 6.21, “Using NLVM with Linux Software RAIDs,” on page 76 
¢ Section 6.22, "Virtualization," on page 77 
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6.1 AFP 


* Section 6.1.1, "Anti-Virus Solutions and AFP," on page 64 


6.1.1 Anti-Virus Solutions and AFP 


The Apple Filing Protocol (AFP) support for NSS files on OES is implemented via a technology that 
bypasses the real-time scanning employed by most anti-virus solutions for OES. 


NSS files shared through an AFP connection can be protected by on-demand scanning on the OES 
server or by real-time and on-demand scanning on the Apple client. 


62 Avoiding POSIX and eDirectory Duplications 


OES servers can be accessed by 


* Local (POSIX) users that are created on the server itself. 


* eDirectory users that are given local access through Linux User Manager (LUM). 
However, there are some issues you need to consider: 


¢ Section 6.2.1, "The Problem,” on page 64 
¢ Section 6.2.2, "Three Examples," on page 64 
¢ Section 6.2.3, "Avoiding Duplication," on page 65 


6.2.1 The Problem 


There is no cross-checking between POSIX and eDirectory to prevent the creation of users or groups 
with duplicate names. 


When duplicate names occur, the resulting problems are very difficult to troubleshoot because 
everything on both the eDirectory side and the POSIX side appears to be configured correctly. The 
most common problem is that LUM-enabled users can’t access data and services as expected but 
other errors could surface as well. 


Unless you are aware of the users and groups in both systems, especially those that are system- 
created, you might easily create an invalid configuration on an OES server. 


6.2.2 Three Examples 


The following examples illustrate the issue. 


+ “The shadow Group" on page 65 
* "The users Group" on page 65 


+ "Other Non-System Groups" on page 65 
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6.2.3 


The shadow Group 


There is a default system-created group named shadow that is used by certain Web-related services, 
but it has no relationship with Dynamic Storage Technology (DST) and shadow volumes. 


Because shadow is a local POSIX group, there is nothing to prevent you from creating a LUM- 
enabled second group in eDirectory that is also named shadow. In fact, this could be a logical name 
choice for many administrators in conjunction with setting up shadow volume access for Samba/CIFS 
users. 


However, using this group name results in LUM-enabled users being denied access by POSIX, which 
looks first to the local shadow group when determining access rights and only checks eDirectory for a 
group named shadow if no local group is found. 


The users Group 


There is another default system-created group named users that is not used by OES 2015 or later 
services but is nevertheless created on all SLES 11 (and therefore, OES 2015 SP1or later) servers. 


Creating an eDirectory group named users would seem logical to many administrators. And as with 
the shadow group, nothing prevents you from using this name. 


Unfortunately, having a LUM-enabled eDirectory group named users is not a viable configuration for 
services requiring POSIX access. The local users group is always checked first, and the LUM- 
enabled users group in eDirectory won't be seen by POSIX. 


NOTE: Do not confuse eDirectory Group objects with Organizational Unit (OU) container objects. 


Creating an OU container in eDirectory named users is a valid option and does not create conflicts 
with POSIX. 


Other Non-System Groups 


Conflicts between group and user names also occur when administrators create local and eDirectory 
groups with the same name. 


For example, one administrator creates a group named myusers on the local system and another 
creates a LUM-enabled group in eDirectory with the same name. Again, the LUM-enabled users who 
are members of the eDirectory group won't have access through POSIX. 


This is why we recommend that, as a general rule, administrators should not create local users or 
groups on OES servers. You should only make exceptions when you have determined that using 
LUM-enabled users and groups is not a viable option and that objects with the same names as the 
POSIX users and groups will not be created in eDirectory in the future. 


Avoiding Duplication 
Having duplicate users and groups is easily avoided by following these guidelines: 


* "Use YaST to List All System-Created Users and Groups" on page 66 


* "Create Only eDirectory Users and Groups" on page 66 
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6.3 


6.3.1 


6.3.2 


Use YaST to List All System-Created Users and Groups 


We recommend that you use the YaST Group Management/User Management module to check for 
names you might duplicate by mistake. 

1. Open the YaST Control Center. 

2. Click either Group Management or User Management. 

3. Click Set Filter » Customize Filter. 

4. Select both options (Local and System), then click OK. 


All users or groups as displayed, including those that exist only in eDirectory and are LUM- 
enabled. 


5. To avoid duplication, keep this list in mind as you create eDirectory users and groups. 


NOTE: The list of users and groups in Appendix H, "System User and Group Management in OES 
2015 SP1," on page 257 is not exhaustive. For example, the users group is not listed. 


Create Only eDirectory Users and Groups 


The LUM technology eliminates the need for local users and groups. We recommend, therefore, that 
you avoid the problems discussed in this section by not creating local users and groups. 


CIFS 


* Section 6.3.1, "Changing the Server IP Address,” on page 66 


* Section 6.3.2, "Renaming CIFS Share Names on NSS Volumes Results in Two Share Names," 
on page 66 


Changing the Server IP Address 


Reconfiguring CIFS in YaST might not take effect if the server IP address was changed on the server 
but not in the OES LDAP server configuration. 


To work around this: 


1 Reconfigure the LDAP server IP address with the IP address changes. 
2 Then change the CIFS IP address configuration. 


Renaming CIFS Share Names on NSS Volumes Results in 
Two Share Names 


When NSS volumes are added to an OES server, they are automatically added as CIFS shares. 


If you rename these shares and restart CIFS, the original share names appear in addition to the new 
share names you specified. 
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6.4 


6.5 


6.6 


6.6.1 


6.6.2 


CUPS on OES 


iPrint is the print solution for OES and offers more robust and scalable print services than a CUPS 
installation can. iPrint actually uses CUPS to render print jobs prior to sending them to the printer, but 
for scalability and performance, printing from the server itself is disabled during iPrint installation. 


If you plan to use iPrint, deselect Print Server in the Primary Functions category during the install 
and don't configure CUPS on the OES server. 


DSfW: MMC Password Management Limitation 


After creating a user, you cannot then force a password change through the Microsoft Management 
Console (MMC) because the User must change password at next logon option is disabled. You can 
work around this issue while creating the user by selecting the option as part of the creation task. For 
existing users, you can reset the password and select the same option as part of the reset task. 


eDirectory 


¢ Section 6.6.1, “Avoid Uninstalling eDirectory When Possible,” on page 67 

¢ Section 6.6.2, “Avoid Renaming Trees and Containers,” on page 67 

¢ Section 6.6.3, "Default Static Cache Limit Might Be Inadequate,” on page 68 

* Section 6.6.4, “eDirectory Not Restarting Automatically,” on page 68 

* Section 6.6.5, "One Instance Only,” on page 68 

* Section 6.6.6, "Special Characters in Usernames and Passwords,” on page 68 


Avoid Uninstalling eDirectory When Possible 


OES services are tightly integrated with eDirectory and do not function without it. 


The process of uninstalling and reinstalling eDirectory is documented in “Reconfiguring eDirectory 
and OES Services " in the OES 2015 SP1: Installation Guide. However, you should carefully consider 
the potential ramifications of doing this. The documented solution has been thoroughly tested, but it is 
impossible for Novell to anticipate all customer scenarios and the complications that might arise in 
them. 


If you have an issue that you believe can only be resolved by uninstalling and reinstalling eDirectory, 
we recommend that you consult with Novell Technical Services before you attempt to do so. 


IMPORTANT: Although the eDirectory 8.8 documentation describes how to remove and reinstall 
eDirectory, the processes described in that documentation do not cleanly decouple OES services, nor 
do they restore service connections. Therefore, they do not apply to OES servers. 


Avoid Renaming Trees and Containers 


The configuration files for many OES services point to configuration data stored within eDirectory. 


Although eDirectory tracks all changes internally, OES services do not. Therefore, if you rename your 
eDirectory tree or one of the containers below [Root], you should expect that one or more of your 
OES services will break. 
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68 


6.6.3 


6.6.4 


6.6.5 


6.6.6 


If you need to rename a container or tree, make sure that you 


1. Identify all of the configuration files for your OES services. 
2. Assess whether the changes that you are planning impact any of your service configurations. 


3. Understand and articulate the changes that are required to restore your services after renaming. 


There are no automated tools in OES for resolving the configuration errors and other problems that 
are caused by renaming a tree or its containers. 


Default Static Cache Limit Might Be Inadequate 


The eDirectory install in OES 2015 or later sets a default static cache of 200 MB if an. ndsdb.ini file 
is not present in the dib directory. 


To improve performance, you can adjust the cache parameter in the _ndsdb. ini file after the install 
to meet your eDirectory performance requirements, depending on the database size and available 
system RAM. We recommend setting the cache to 200 MB on a 2 GB RAM system and 512 MB on 4 
GB RAM system. 


eDirectory Not Restarting Automatically 


After a system crash or power failure, eDirectory services (ndsd) might not automatically restart in 
some situations. To start eDirectory again, do the following: 


1 Delete the /var/opt/novell/eDirectory/data/ndsd. pid file. 


2 Ataterminal prompt, enter /etc/init.d/ndsd start. 


One Instance Only 


OES supports only one instance of eDirectory (meaning one tree instance) per server. 


If you need two or more instances running on a single server, you must install them on a non-OES 
server, such as SLES 11. 


Special Characters in Usernames and Passwords 


Using special characters in usernames and passwords can create problems when the values are 
passed during an eDirectory installation or schema extension. 


If the username or password contains special characters, such as $, #, and so on, escape the 
character by preceding it with a backslash (V). For example, an administrator username of 


cn-admin$name.o-container 
must be passed as 
cn-adminN$name.o-container 


When entering parameter values at the command line, you can either escape the character or place 
single quotes around the value. For example: 


cn-adminN$name.o-container 
Or 


'cnzadmin$name.o-container ' 
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6.7 


6.8 


6.8.1 


6.8.2 


6.8.3 


6.8.4 


iFolder 3.9.2 


Implementation caveats for iFolder 3.9.2 are documented in "Caveats for Implementing iFolder 
Services" in the Novell iFolder 3.9.2 Administration Guide. 


IPrint 
iPrint has the following implementation caveats: 


¢ Section 6.8.1, "Advanced Printing Options," on page 69 


¢ Section 6.8.2, "Authentication Dialog Not Displaying for Secure Printers from Terminal Servers,” 
on page 69 


¢ Section 6.8.3, "Cluster Failover Between Mixed Platforms Not Supported,” on page 69 
¢ Section 6.8.4, “iManager Plug-Ins Are Platform-Specific," on page 69 

¢ Section 6.8.5, "iPrint Client for Linux Doesn't Install Automatically," on page 70 

* Section 6.8.6, "iPrint Disables CUPS Printing on the OES Server,” on page 70 


¢ Section 6.8.7, "Linux and Macintosh Client Printer Installation Fails When Communicating via 
Proxy," on page 70 


¢ Section 6.8.8, "Printer Driver Uploading on OES Might Require a CUPS Administrator 
Credential," on page 70 


Advanced Printing Options 


Some drivers, such as HP and Lexmark UPDs, have problems handling advanced printing options, 
such as watermarks and n-up printing when they are used from user workstations. 


Authentication Dialog Not Displaying for Secure Printers 
from Terminal Servers 


When you perform an automatic driver or profile update for secure printers from terminal servers, the 
authentication dialog box is not displayed. 


Cluster Failover Between Mixed Platforms Not Supported 


Clustered iPrint services can only fail over to the same platform, either OES or NetWare. 


iManager Plug-Ins Are Platform-Specific 
The iManager plug-ins are different for each server platform. Therefore, if you have both OES and 


NetWare 6.5 SP8 servers running iPrint services, you need two instances of iManager to manage 
iPrint—one on each platform. 
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6.8.5 


6.8.6 


6.8.7 


6.8.8 


6.9 


iPrint Client for Linux Doesn't Install Automatically 


Users who are used to installing the Windows iPrint Client expect to choose an Open option and have 
the client install automatically. However, installing the client on Linux workstations requires you to 
save the RPM package and then install it manually if a package manager is not already installed and 
configured as it is in the Novell Linux Desktop. For more information, see "Linux: iPrint Client" in the 
OES 2015 SP1: iPrint Linux Administration Guide. 


iPrint Disables CUPS Printing on the OES Server 


iPrint uses CUPS to render print jobs before sending the print job to the Print Manager. For 
performance and scalability, printing from the server itself is disabled during the OES installation of 
iPrint. 


Linux and Macintosh Client Printer Installation Fails When 
Communicating via Proxy 


Linux and Macintosh iPrint clients fail to install printers when communicating with the iPrint server 
through a proxy server. 


Printer Driver Uploading on OES Might Require a CUPS 
Administrator Credential 


A PPD is the Linux equivalent of a printer driver on Windows. 


There are two versions of the iPrint Client: high security and low security. End users and 
administrators install the high-security client when using the iPrint Printer List Web page. 


This means that administrators are prompted for a CUPS administrator credential when uploading 
PPDs. However, the prompt doesn't specify that a CUPS administrator credential is needed and the 
root user credential does not work. 


LDAP—Preventing "Bad XML" Errors 


If you are using NetIQ eDirectory 8.7.3x, time outs are possible when you search from iManager for 
eDirectory objects, such as NCP Server objects, Volume objects, and Cluster objects. This is 
because the Object Class attribute is not indexed by default. The LDAP sub-tree search can take 
over 30 seconds, which causes the query to time out. For example, a Cluster objects search from the 
Cluster Options page returns the error: 


Bad XML found during parsing when accessing cluster options 


We recommend that you create a value index on the objects' Object Class attribute. (Object Class is 
considered an attribute for indexing purposes.) This helps to reduce the time needed for the subtree 
search from over 30 seconds to 10 to 50 milliseconds. For instructions, see "Creating an Index” in the 
NetIQ eDirectory 8.8 SP8 Administration Guide. 


Building indexes speeds up the subtree search, even if some partitions being searched do not contain 
these types of objects. For example, searching for a Cluster object in a context that contains only 
users is not expected to return results; however, the Object Class search is still performed, and 
benefits from having an index present. 
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The subtree search performance issue is resolved in the eDirectory 8.8 release with the addition of 
the AncestorID feature. 


6.10 LUM Cache Refresh No Longer Persistent 


In response to customer requests for improved LDAP performance, persistent searching for new 
Linux-enabled users and groups was disabled in OES 2 and has been carried forward in OES 2015 
or later. This means that when a user or group is enabled for Linux access, it is not immediately listed 
in some of the interfaces, such as the GUI file browser. 


For most installations this is not an issue. However, persistent searching can be turned on by editing 
the /etc/nam.conf file and changing the persistent-search parameter from no to yes. 


Alternatively, you can shorten the LUM cache refresh period (default is 8 hours). You can adjust the 
refresh period by editing the persistent-cache-refresh-period parameter in the /etc/nam.conf 
file and restarting LUM using the rcnamcd restart command. 


You can also refresh the cache immediately by using the namconfig cache refresh command. 


For more information, see "The namcd Linux User Management Caching Daemon" in the OES 2015 
SP1: Linux User Management Administration Guide. 


6.11 Management 


* Section 6.11.1, "iManager RBS Configuration with OES," on page 71 
* Section 6.11.2, "Storage Error in iManager When Accessing a Virtual Server,” on page 72 


* Section 6.11.3, "Truncated DOS-Compatible Short Filenames Are Not Supported at a Terminal 
Prompt," on page 72 


¢ Section 6.11.4, "LUM-Enabling Required for Full Administrative Access,” on page 72 


6.11.1 iManager RBS Configuration with OES 


In “Installing RBS" in the NetiQ® iManager Administration Guide, you are instructed to run the 
iManager Configuration Wizard before using iManager. 


When iManager is installed in connection with OES, various roles and tasks are configured, as shown 
in Figure 6-1. 


These roles and tasks are available to all the users you create until you run the configuration wizard. 
After that, the roles and tasks are available only to the Admin user and other users or groups you 
specifically designate. 


Caveats for Implementing OES 2015 SP1 Services 71 


6.11.2 


6.11.3 


6.11.4 


Figure 6-1 iManager Roles and Tasks 


A] Roles and Tasks 
@ Available Novell Plug-in Modules 


[All Categories] v 
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Success: The plug-in module has been successfully installed. 


You must now restart Tomcat in order for the changes to take effect. 
After Tomcat restarts, if Role Based Services is installed you will need to 


configure the newly installed modules. 


For more information on iManager, see the NetIQ® iManager Administration Guide. 


Storage Error in iManager When Accessing a Virtual Server 


iManager returns a Storage Error when you access the Authentication tab for a virtual server 
object. This is working as designed. 


Truncated DOS-Compatible Short Filenames Are Not 
Supported at a Terminal Prompt 


Use the actual filenames instead of names such as filena-1.txt during file operations from the 
command prompt. 


LUM-Enabling Required for Full Administrative Access 


The current LUM architecture requires that administrators, administrator equivalents, and RBS- 
enabled managers be LUM-enabled to have full management capabilities. 
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6.12 


6.13 


6.13.1 


McAfee Antivirus Requires Additional 
Configuration 


After installing McAfee Antivirus support on an OES server with NSS and/or NCP volumes, various 
problems might be seen, including clustered volumes going comatose because of mount failures with 
an error code of 150. 


This happens because the antivirus software is locking . trustee dabase.xml files on NSS and NCP 
volumes. 


To prevent these problems, make sure you do the following, as described in the McAfee 
documentation. (References to OES 2 apply to OES 2015 or later as well.) 


1 Exclude the NETWARE and / admin/* folders on all NSS and NCP volumes as documented in 
Chapter 5 » Anti-virus Exclusions in the McAfee VirusScan Enterprise for Linux 1.7.0 Best 
Practices Guide, except that the / admin/* path is documented incorrectly as ADMIN in the 
McAfee guide. 


For example: 
* / admin/* (for NSS) 
* /admin/* (for NCS) 
* /media/nss/volume name/. NETWARE 


2 Using iManager, create a nails user and a nailsgroup group in eDirectory and assign them 
administrative privileges on all NSS and/or NCP volumes as documented in Chapter 2 » 
Prerequisites in the McAfee VirusScan Enterprise for Linux 1.7.0 Software Configuration Guide. 


IMPORTANT: Be sure to configure any new NSS or NCP volumes you add to the server. 


NCP 


* Section 6.13.1, "NCP Doesn't Equal NSS File Attribute Support," on page 73 
* Section 6.13.2, "Opening MS Office Files Using Novell Client for Windows 7," on page 74 


NCP Doesn't Equal NSS File Attribute Support 


NSS file attributes and NCP services tend to get mixed together in the minds of OES administrators, 
especially those with a lot of NetWare experience. It is important to remember that file and directory 
attributes are supported and enforced by the file system that underlies an NCP volume, not by the 
NCP server. 


For example, even though the Rename Inhibit attribute appears to be settable in the NCP client 
interface, if the underlying file system is Linux POSIX (Ext3, XFS, and so on) there is no support for 
the attribute and it cannot be set. 


Salvage (undelete) and Purge are other features that are available only on NSS and only where the 
Salvage attribute has been set (the NSS default). They can be managed in the NCP client and 
through NetStorage, but they are not available on NCP volumes where the underlying file system is 
Linux POSIX. 


Some administrators assume they can provide NSS attribute support by copying or migrating files, 
directories, and metadata from an NSS volume to a defined NCP volume on a Linux POSIX partition. 
However, this doesn't work, because NSS file attributes are only supported on NSS volumes. 
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6.13.2 


6.14 


6.14.1 


6.14.2 


Opening MS Office Files Using Novell Client for Windows 7 


To open MS Office files through an NCP (Novell Client) connection, Windows 7 workstations must be 
running Novell Client 2 SP1 for Windows, version IR 9a or later. Otherwise, file open requests are 
denied. See TID 7009540 (http://www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=7009540&sliceld=1&docTypelD=DT_TID_1 1 
&dialoglD-273023280&stateld-0962009620273025163). 


Windows XP workstations do not experience the problem. The latest version of Novell Client for 
Windows XP is version 4.91 SP5 (IR2). 


Novell Identity Translator (NIT) 


Novell Identity Translator is a new service in OES 2015. 


¢ Section 6.14.1, “NIT and LUM UID Ranges Must Not Overlap,” on page 74 
¢ Section 6.14.2, "Choosing the Best NIT Generate-Mode Settings for Your AD Users,” on page 74 


¢ Section 6.14.3, “Actions that Require a Server Restart,” on page 75 


NIT and LUM UID Ranges Must Not Overlap 


Ensure that Your LUM and NIT UID Ranges Don’t Overlap. 


For more information, see “Not All Users Have UIDs by Default” and “Ensuring that Your CIFS-NSS 
Users Have UIDs” in the OES 2015 SP1: NSS AD Administration Guide. 


Choosing the Best NIT Generate-Mode Settings for Your AD 
Users 


For AD users, NIT runs in one of two modes, as outlined in Table 6-1. 
Table 6-1 NIT AD-UID Mode Summary 


AD-UID Mode Details 


Generate * Default mode 
* /etc/opt/novell/nit/nitd.conf » ad-uid-generate-mode-1 
(The option is enabled.) 


* NIT generates UIDs for all users and groups that need them, ignoring the 
uidNumber attribute in Active Directory. 


* NSS is accessible to all otherwise-qualified AD users and groups. 
Fetch + /etc/opt/novell/nit/nitd.conf > ad-uid-generate-mode=0 


(The option is disabled.) 


* NIT retrieves UIDs for AD users and groups that have the uidNumber attribute in 
Active Directory 


* NSS is accessible only to AD users and groups that have the uidNumber attribute in 
Active Directory. 
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6.14.3 


6.15 


6.16 


6.16.1 


6.16.2 


6.17 


Actions that Require a Server Restart 


The following changes to a server's NIT configuration require a server restart: 
* Changing the AD-UID Generate mode (ad-uid-generate-mode in the nitd.conf file). 


The two mutually exclusive options are "Generate" and "Fetch." 
* Changing the UID range that NIT uses (uid-start-range or uid-end-range in the nitd.conf file). 


For more information, see "NIT (Novell Identity Translator)" in the OES 2015 SP1: NSS AD 
Administration Guide. 


Novell-tomcat Is for OES Use Only 


The novell-tomcat package is installed and configured for OES service use only. It is an integral, 
embedded part of Novell OES services, not a generic application platform. 


The novell-tomcat package, and its associated configuration file and JRE (novell-tomcat.conf 
and IBM 1.6.0 Java), must not be manually modified, updated, or changed in any way. Otherwise, 
OES services and tools, such as iManager, do not work as expected. 


If you want to deploy a Tomcat-dependant Web application on an OES server, use the open source 
Tomcat package that comes with SLES 11. Installing and configuring the open source Tomcat 
package will not affect the novell-tomcat package. 


NSS 


* Section 6.16.1, "For GroupWise, Change the Default Name Space to UNIX," on page 75 
* Section 6.16.2, "Junction Target Support," on page 75 


For GroupWise, Change the Default Name Space to UNIX 


NSS stores LONG, UNIX, DOS, and AFP name spaces for all files. The default name space sets 
which name space will be exposed. 


In OES 2015 or later the LONG name space is the default to help performance of NCP, CIFS, and 
Samba file services. If your primary use is for GroupWise, we recommend changing the default name 
space to UNIX. 


Junction Target Support 


If a junction's source and target are both on OES, then subdirectory targets are fully supported. 
Junctions from OES to NetWare only support targets at the root of a volume. 


NetWare junctions cannot target OES servers. 


OpenLDAP on OES 


You cannot run OpenLDAP on an OES server with eDirectory installed. eDirectory LDAP is required 
for OES services and uses the same ports as OpenLDAP. 
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6.18 


6.19 


6.20 


6.21 


Samba 


For Samba implementation caveats, see "Samba Caveats” in the OES 2015 SP1: Novell Samba 
Administration Guide. 


SLP Registrations Are Not Retrieved from a Novell 
SLP DA 


By default, the OpenSLP DA cannot retrieve SLP registrations from the Novell SLP DA during 
startup. For information on resolving this issue, see TID 7009783 (http://www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=7009783&sliceld=1&docTypelD=DT_TID_1 1 
&dialoglD-281740290&stateld-096200962028173687 7). 


Synchronizing NMAS Login Methods Is Required 
to Avoid Login Failures 


NMAS (NetIQ Modular Authentication Service) provides flexible login options, including support for 
smart cards, proximity cards, passwords, etc. 


OES services, such as Novell AFP and Novell CIFS include NMAS login methods that are installed in 
eDirectory at the same time as the services. Macintosh and Windows users can then log into OES 
just as they would log into a native AFP or CIFS server. 


After an NMAS login method is installed in eDirectory, it must be synchronized to all of the eDirectory 
replicas in the tree. Replica synchronization is, of course, a high system priority. However, it is not 
guaranteed to be immediate, and on networks with many servers and multiple-replica trees, normal 
delays in synchronization can result in authentication failures. 


For example, when an AFP user requests a connection to an OES server running Novell AFP, NMAS 
can direct the login request to any eDirectory server that has a writable replica of a partition 
containing the User object. If the AFP login method is not yet synchronized to that particular 
eDirectory server, the authentication request fails. 


To avoid login failures and user frustration, you should make sure that all of your eDirectory servers 
that hold replicas are synchronized as soon as possible after OES services are installed. 


For more information on synchronization, see "Synchronization" in the Net/Q eDirectory 8.8 SP8 
Administration Guide. 


Using NLVM with Linux Software RAIDs 


Linux Software RAIDs are intended to be used with Linux tools and file systems. Consider the 
caveats in this section before implementing Linux Software RAIDS on your OES server. 

* Section 6.21.1, "Linux Software RAIDs," on page 77 

« Section 6.21.2, "Linux Software RAIDs Are Not Cluster Aware," on page 77 


¢ Section 6.21.3, "Linux Software RAIDs Are Not Recommended for the System Device,” on 
page 77 
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6.211 Linux Software RAIDs 


We recommend that you do not use Linux software RAIDs (such as MD RAIDs and Device Mapper 
RAIDs) for devices that you plan to use for storage objects that are managed by NSS management 
tools. The Novell Linux Volume Manager (NLVM) utility and the NSS Management Utility (NSSMU) 
list Linux software RAID devices that you have created by using Linux tools. Beginning with Linux 
Kernel 3.0 in OES 11 SP1, NLVM and NSSMU can see these devices, initialize them, and allow you 
to create storage objects on them. However, this capability has not yet been fully tested. 


IMPORTANT: In OES 11 or later, a server hang or crash can occur if you attempt to use a Linux 
software RAID when you create storage objects that are managed by NSS management tools. 


For NSS pools, you can use hardware RAID devices or NSS Software RAID devices to achieve disk 
fault tolerance. 


For Linux POSIX volumes, L VM volume groups, and cLVM volume groups, you can use hardware 
RAID devices on your storage subsystem to achieve disk fault tolerance. 


6.21.2 Linux Software RAIDs Are Not Cluster Aware 


Do not use Linux Software RAIDs for devices that you plan to use for shared storage objects. Linux 

Software RAID devices do not support concurrent activation on multiple nodes; that is, they are not 

cluster aware. They cannot be used for shared-disk storage objects, such as the OCFS2 file system, 
cLVM volume groups, and Novell Cluster Services SBD (split-brain-detector) partitions. 


For shared disks, you can use hardware RAID devices on your storage subsystem to achieve fault 
tolerance. 


6.21.3 Linux Software RAIDs Are Not Recommended for the 
System Device 


We recommend that you do not use Linux software RAIDs (such as MD RAIDs and Device Mapper 
RAIDs) on the system device if you plan to use free space on the device later for storage objects 
managed by NSS tools. During the SLES and OES installation, if you create a Linux software RAID 
device to use as the system device for the root (/) file system, the free space on the system device 
cannot be used later for NSS pools because the configuration of NSS storage objects on Linux 
software RAIDs has not yet been fully tested. 


IMPORTANT: In OES 11, a server hang or crash can occur if you attempt to use a Linux software 
RAID when you create storage objects that are managed by NSS management tools. 


For the Linux system device, you can use a hardware RAID device to achieve fault tolerance. This 
allows NSS tools to see and use any available free space on the system device for unshared NSS 
pools. 


6.22 Virtualization 


The following are caveats for setting up OES server in Xen VMs: 


¢ Section 6.22.1, "Always Close Virtual Machine Manager When Not in Use,” on page 78 
¢ Section 6.22.2, "Always Use Timesync Rather Than NTP,” on page 78 
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6.22.1 


6.22.2 


6.22.3 


6.22.4 


6.22.5 


¢ Section 6.22.3, "Backing Up a Xen Virtual Machine," on page 78 
* Section 6.22.4, “Time Synchronization and Virtualized OES,” on page 78 
* Section 6.22.5, “NSS Considerations," on page 78 


Always Close Virtual Machine Manager When Not in Use 


You should always close Virtual Machine Manager (VMM) when you are not actively using it. Virtual 
Machines are not affected. 


Leaving VMM open can affect the system resources available to the VMs. 


Always Use Timesync Rather Than NTP 


Time synchronization problems have been observed when virtualized NetWare servers are running 
the XNTPD NLM. Therefore, Novell strongly recommends using Timesync and also configuring the 
service to communicate through NTP. 


Backing Up a Xen Virtual Machine 


When backing up a Xen virtual machine running virtualized NetWare, we recommend using a remote 
backup source rather than a local tape device because of limitations in detecting a local tape device. 


Time Synchronization and Virtualized OES 


eDirectory relies on time being synchronized and connections with eDirectory are lost if the system 
time varies in the host operating system. Be sure you understand and follow the instructions in Virtual 
Machine Clock Settings (http://www.suse.com/documentation/sles11/book xen/data/ 

sec xen guests suse time.html) in the Virtualization with Xen (http:/Awww.suse.com/documentation/ 
sles11/book xen/data/book xen.html) guide. 


NSS Considerations 


Make sure you follow these guidelines for using NSS volumes in connection with OES servers 
running in Xen VMs: 


* OES: Data shredding is not supported. 
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7.1 


7.1.1 


7.1.2 


7.2 


Upgrading to OES 2015 SP1 


This section provides information and links for upgrading to Open Enterprise Server. 


¢ Section 7.1, “Caveats to Consider Before Upgrading,” on page 79 
¢ Section 7.2, “OES 2015 SP1 Upgrade Paths,” on page 79 
¢ Section 7.3, “NetWare 6.5 SP8 Upgrade Paths,” on page 80 


Caveats to Consider Before Upgrading 


Be aware of the following caveats when upgrading an OES server: 


¢ Section 7.1.1, "About Previously Installed Packages (RPMs),” on page 79 
* Section 7.1.2, "Only One eDirectory Instance Is Supported on OES Servers,” on page 79 


About Previously Installed Packages (RPMs) 


Other Novell products, such as GroupWise, and third-party applications that you have installed are 


treated differently by default when you upgrade an OES server, depending on the version of the 
server you are upgrading. 


To learn more and for instructions on manually changing these options, see "Planning for the 
Upgrade to OES 2015 SP1" in the OES 2015 SP1: Installation Guide. 


Only One eDirectory Instance Is Supported on OES Servers 


If your OES server has multiple instances of eDirectory running (multiple trees), any attempt to 
upgrade the server fails. 


You must remove all instances, except the one that uses port 524, prior to an upgrade. 


For more information, see Section 6.6.5, "One Instance Only," on page 68. 


OES 2015 SP1 Upgrade Paths 


The following are supported upgrade paths for OES 2015 SP1: 


Table 7-1 Supported OES 2015 SP1 Upgrade Paths 


Source Destination 
OES 2015 OES 2015 SP1 
OES 11 SP2, OES 11 SP3 OES 2015 SP1 
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NOTE: Physical installations cannot be upgraded to virtual installations, and the reverse is also true. 
Only physical to physical and virtual to virtual upgrades are supported. 


For complete upgrade instructions, see "Upgrading to OES 2015 SP1” in the OES 2015 SP1: 
Installation Guide. 


In addition to upgrading the server itself, data and service migrations are also supported. For more 
information, see "Planning for Migration" in the OES 2015 SP1: Migration Tool Administration Guide. 


7.3 NetWare 6.5 SP8 Upgrade Paths 


For help upgrading from NetWare to OES 2015 SP1, see the OES 2015 SP1: Upgrading to OES— 
Best Practices Guide. 
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8.1 


8.2 


Migrating Existing Servers and Data 


This section briefly outlines the following migration topics: 


¢ Section 8.1, “Supported OES 2015 SP1 Migration Paths,” on page 81 


¢ Section 8.2, “Migration Tools and Purposes,” on page 81 


Supported OES 2015 SP1 Migration Paths 


For a complete list of Open Enterprise Server migration scenarios and paths, see “Migration 
Scenarios" in the OES 2015 SP1: Migration Tool Administration Guide. 


Migration Tools and Purposes 


The OES 2015 SP1 Migration Tool lets you migrate and/or consolidate data and services from one or 
more NetWare and OES source servers to an OES 2015 SP1 target server. See "Source Platform 
Support for OES 2015 SP1 Services " in the OES 2015 SP1: Migration Tool Administration Guide. 


You can also transfer a complete server identity, including its IP address, hostname, eDirectory 
identity, NICI keys, and certificates. For more information, see "Transfer ID " in the OES 2015 SP1: 
Migration Tool Administration Guide. 
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9.1 


Virtualization in OES 2015 SP1 


Open Enterprise Server 2015 SP1 runs as a VM guest on any virtual machine host server that is 
certified for running SUSE Linux Enterprise Server 11 SP4 (SLES 11 SP4) as a virtualized guest. 
Because Xen and KVM are distributed with SLES 11 SP4, they are mentioned more particularly in the 
OES documentation. 


For a list of the VM host platforms that are certified for SLES 11 SP4, see Section 2.2.4, "Supported 
Virtualization Hosts" (https://www.suse.com/documentation/sles11/book sle deployment/data/ 

sec x86 sysregs.html) in the SLES 11 Deployment Guide (https://www.suse.com/documentation/ 
sles11/book sle deployment/data/book sle deployment.html). 


NetWare guest servers are supported only on Xen host servers. NetWare is not supported as a guest 
on a KVM virtual machine host server. 


For information about installing and running OES 2015 SP1 services on virtual machines, see the 
links on the Virtualization page of the OES 11 Online Documentation (http://www.novell.com/ 
documentation/oes11/index.htmlZcat virtualization). 

¢ Section 9.1, "Graphical Overview of Virtualization in OES 2015 SP1,” on page 83 

¢ Section 9.2, "Why Install OES Services on Your VM Host?,” on page 84 

* Section 9.3, "Services Supported on VM Hosts and Guests," on page 85 

¢ Section 9.4, “Xen VMs Need Ext2 for the System /Boot Volume,” on page 86 


IMPORTANT: Support for Xen virtualization of NetWare 6.5 SP7 and later is an OES product feature 
and is available only to OES registered customers. 


Graphical Overview of Virtualization in OES 2015 
SP1 


Figure 9-1 illustrates how a single VM host server can support multiple VM guest servers that in turn 
provide OES services. 
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Figure 9-1 Virtualization in OES 2015 SP1 
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9.2 Why Install OES Services on Your VM Host? 


Novell supports four OES services running on a Xen VM host server: Novell Linux User Management, 
Novell Storage Management Services, Novell Cluster Services, and iPrint. 


Having these components installed on a Xen VM host server provides the following benefits: 


* Linux User Management (LUM): Lets you SSH into the server for management purposes by 
using an eDirectory user account. 


This functionality requires that you 
* Enable SSH communications through any firewalls that are running on the server 


* Configure LUM to allow SSH as a LUM-enabled service. For more information see 
"Section 11.4.2, "Setting Up SSH Access for LUM-enabled eDirectory Users," on page 94." 


* Storage Management Services (SMS): Lets you back up VM host server file system data. 
* Novell Cluster Services (NCS): Lets you cluster the VM host. 
* Micro Focus iPrint: Lets you print from the host. 
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9.3 


Services Supported on VM Hosts and Guests 


As you plan your virtualization configurations, you will want to consider which services are supported 
where Table 9-1 and which combinations of services are supported (see Section 3.8.21, 
"Unsupported Service Combinations," on page 49). 


Table 9-1 Services Supported on VM Hosts and Guests 


OES 2015 SP1 Service Linux VM Host 


AFP (Novell AFP) 
Backup/SMS "d 
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9.4 


IMPORTANT: Adding OES services to a Xen VM host requires that you boot the server with the 
regular kernel prior to adding the services. See the instructions in the Important note in "Adding/ 
Configuring OES Services on an Existing Server" in the OES 2015 SP1: Installation Guide. 


Xen VMs Need Ext2 for the System /Boot Volume 


It is recommended that operating systems running in paravirtual mode set up their kernel on a 
separate partition that uses a non-journaling file system, such as ext2. 


Before a paravirtualized operating system can boot, the management domain must construct a virtual 
machine and place the paravirtualized kernel in it. Then, the paravirtualized operating system boots. 
To retrieve the kernel during the bootstrapping process, the virtual machine's boot disk is mounted in 
read-only mode, the kernel is copied to the virtual machine's memory, and then the boot disk is 
unmounted. 


When a virtual machine's operating system crashes, its disks are not shut down in an orderly manner. 
This should not pose a problem to a virtual machine running in full virtualization mode because the 
pending disk entries are checked and corrected the next time the operating system starts. If the disk 
is using a journaling file system, the journal is replayed to update and coordinate any pending disk 
entries. 


This type of system crash poses a potential problem for paravirtualized operating systems. If a 
paravirtualized operating system using a journaled file system crashes, any pending disk entries 
cannot be updated and coordinated because the file system is initially mounted in read-only mode. 


Therefore, it is recommended that you set virtual machine boot files, such as the kernel and ramdisk, 
on a separate partition that is formatted with a non-journaling file system, such as ext2. 
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Clustering and High Availability 


Open Enterprise Server 2015 SP1 includes support for a two-node Novell Cluster Services cluster. 


The full Novell Cluster Services product (available through a separate purchase) is a multinode 
clustering product that 

* Can include up to 32 servers. 

* Is supported for both NetWare and OES during the migration to OES. 


For more information, see the OES 2015 SP1: Novell Cluster Services NetWare to Linux 
Conversion Guide. 


¢ Is eDirectory enabled for single-point ease of management. 


* Supports failover, failback, and migration (load balancing) of individually managed cluster 
resources. 


* Supports shared SCSI, iSCSI, and Fibre Channel storage area networks. 


For more information, see the OES 2015 SP1: Novell Cluster Services for Linux Administration 
Guide. 


Clustering and High Availability 


87 


88 Clustering and High Availability 


11.1 


Managing OES 2015 SP1 


This section includes the following topics: 


¢ Section 11.1, "Overview of Management Interfaces and Services,” on page 89 
¢ Section 11.2, “Using OES 2015 SP1 Welcome Pages,” on page 91 

¢ Section 11.3, “iManager and Self-Signed Certificates," on page 92 

¢ Section 11.4, “SSH Services on OES 2015 SP1,” on page 92 


Overview of Management Interfaces and Services 


As shown in Figure 11-1, Open Enterprise Server provides a rich set of service-management and 
server-management tools, including browser-based and server-based interfaces that help you 
implement and maintain your network. Access to most of these management interfaces is controlled 
through eDirectory. However, a few interfaces, such as YaST on SUSE Linux Enterprise Server 11 
servers, require local authentication. 
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Figure 11-1 Management Interfaces and Services 
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11.2.1 


11.2.2 


Using OES 2015 SP1 Welcome Pages 


After you install an OES 2015 SP1 server, anyone with browser access to the server can access its 
Welcome Web site, which is a collection of dynamic Web pages that provides access to management 
tools and software. 


This section explains OES Welcome Web Site features, and discusses: 


¢ Section 11.2.1, “The Welcome Site Requires JavaScript, Apache, and Tomcat,” on page 91 
* Section 11.2.2, "Accessing the Welcome Web Site," on page 91 

* Section 11.2.3, "The Welcome Web Site Is Available to All Users," on page 92 

* Section 11.2.4, "Administrative Access from the Welcome Web Site," on page 92 


The Welcome Site Requires JavaScript, Apache, and 
Tomcat 


Browsers accessing the Welcome site must have JavaScript enabled to function correctly. 


Additionally, it is possible to install OES 2015 SP1 without including the Apache Web Server or the 
Tomcat Servlet Container. For example, the Apache server and Tomcat container are included with 
many of the OES 2015 SP1 server patterns, but not all of them. 


If you are unable to access the Welcome Web site, your server is probably missing one or both of 
these required components. To make the site available, you need to add the components to the OES 
2015 SP1 server. 


Accessing the Welcome Web Site 


Anyone with browser access to an OES 2015 SP1 server can access the Welcome site by doing the 
following: 


1 Open a supported Web browser that has a TCP connection to the network where the OES 2015 
SP1 server is installed. 
2 Enter the URL to the server, using HTTP. 
For example: 
http://server.example.com/welcome 
or 
http://192.168.1.206/welcome 


IMPORTANT: By default, the Welcome site is accessible by entering only the DNS name or IP 
address without the path to /welcome as the URL. However, it displays only when there is no 
index.html file in /srv/www/htdocs. For example, installing the Web and LAMP Server pattern 
installs a page that says "It Works!" and the Welcome site is not displayed. 


If the Welcome page disappears, include /welcome in the access URL. 


For additional information, see "Verifying That the Installation Was Successful" in the OES 2015 
SP1: Installation Guide. 
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11.2.3 


11.2.4 


11.3 


11.4 


11.4.1 


The Welcome Web Site Is Available to All Users 


Although the Welcome Web site is designed primarily for administrators, it can also be accessed and 
used by end users. Keep in mind, however, that the software in the Client Software link is static. For 
the latest client software, such as the iPrint client and Novell Client, refer users to the Novell 
download site. 


Administrative Access from the Welcome Web Site 


Administrators can access any of the administrative tools installed on the server by clicking the 
Management Services link, selecting the tool they want to use, and entering the required 
authentication information. 


If a tool doesn't appear, that means that it or the service that it manages is not installed on the server. 


iManager and Self-Signed Certificates 


As explained in the NetIQ iManager Installation Guide, the iManager instructions for dealing with self- 
signed certificates don't apply to OES Linux. 


OES installs Tomcat and Apache versions that are specific to OES (see Section 6.15, "Novell-tomcat 
Is for OES Use Only," on page 75). For instructions on replacing the self-signed Apache/Tomcat 
certificate on OES, see Section 22.2, "Setting Up Certificate Management," on page 235. 


SSH Services on OES 2015 SP1 


This section documents the following topics: 


¢ Section 11.4.1, “Overview,” on page 92 


¢ Section 11.4.2, "Setting Up SSH Access for LUM-enabled eDirectory Users," on page 94 


Overview 


SSH services on SLES 11 are provided by OpenSSH (http://www.openssh.org), a free version of SSH 
connectivity tools developed by the OpenBSD Project (http://www.openbsd.org/). 


Linux administrators often use SSH to remotely access a server for management purposes, such as 
executing shell commands, transferring files, etc. Because many OES 2015 SP1 services can be 
managed at a command prompt via an SSH session, it is important to understand how SSH access is 
controlled in OES 2015 SP1. 


This section discusses the following topics: 


+ "When Is SSH Access Required?” on page 93 
* "How SSH Access for eDirectory Users Works" on page 93 


¢ "SSH Security Considerations" on page 94 
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When Is SSH Access Required? 


SSH access is required for the following: 


* 


SSH administration access for eDirectory users: For eDirectory users to manage the server 
through an SSH connection, they must have SSH access as LUM-enabled users (eDirectory 
users configured for access to Linux services). 


NOTE: The standard Linux root user is a local user, not an eDirectory user. The root user 
always has SSH access as long as the firewall allows it. 


Access to NSS Volume Management in NetStorage: When an OES 2015 SP1 server has 
NSS volumes, eDirectory contains an object named nssvolumes that provides management 
access to the volumes through the File Access (NetStorage) iManager plug-in. Using the plug-in 
to manage NSS volumes, assign trustee rights, salvage and purge files, etc. requires SSH 
access to the server. 


Although eDirectory administrators can create Storage Location Objects to the NSS volumes 
without SSH access if they know the path to the volume on the POSIX file system and other 
volume information, having SSH access makes administering NSS volumes in NetStorage much 
easier. 


Access to any NetStorage Storage Location Objects based on SSH: The NetStorage server 
provides Web access to directories and files on other servers (or on itself). 


Typically, either an NCP or a CIFS connection is used for connecting the NetStorage server with 
storage targets. However, an SSH connection can also be used, and if it is, the users accessing 
data through the connection must have SSH access to the data on the target servers. 


How SSH Access for eDirectory Users Works 


For eDirectory users, the following work together to control SSH access: 


* 


Firewall: As mentioned, the default firewall configuration on an OES 2015 SP1 server doesn't 
allow SSH connections with the server. This restricts the root user as well. Therefore, the first 
requirement for SSH access is configuring the firewall to allow SSH services. 


Linux User Management (LUM) must allow SSH as a PAM-enabled service: In OES 2015 
SP1, access to SSH and other Linux services is controlled through Linux User Management 
(LUM), and each service must be explicitly included in the LUM configuration as a PAM-enabled 
service on each server. 


PAM-enabling: After SSH is included as a PAM-enabled service on a server, at least one group 
and its users must be enabled for LUM. Only LUM-enabled eDirectory users can have SSH 
access. 


All eDirectory Groups must allow access: SSH access is inherited from the LUM-enabled 
groups that a user belongs to, and access is only granted when all of the groups to which a user 
belongs allow it. 


The Samba connection: Users who are enabled for Samba (CIFS) file services are added by 
default to an OES-created Samba group that: 


* Is LUM-enabled. 
* Doesn't specify SSH as an allowed service. 


Therefore, because SSH access requires that all of a user's groups must all allow access, 
Samba users are denied SSH access unless 


* The user is removed from the Samba group. 
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Or 
* The Samba group is modified to allow SSH access for all Samba users. 


SSH Security Considerations 


Remember that SSH access lets users browse and view most directories and files on a Linux server. 
Even though users might be prevented from modifying settings or effecting other changes, there are 
serious security and confidentiality issues to consider before granting SSH access to a group of 
users. 


11.4.2 Setting Up SSH Access for LUM-enabled eDirectory Users 


If you need to grant SSH access to an eDirectory user, complete the instructions in the following 
sections in order, as they apply to your situation. 


+ “Allowing SSH Access Through the Firewall" on page 94 

* "Adding SSH as an Allowed Service in LUM" on page 94 

¢ "Enabling Users for LUM” on page 95 

* "Restricting SSH Access to Only Certain LUM-Enabled Users" on page 95 


+ "Providing SSH Access for Samba Users" on page 96 
Allowing SSH Access Through the Firewall 


NOTE: This section assumes you are allowing SSH access on an installed server. 


SSH can also be enabled during an OES installation by clicking the SSH Port Is Blocked button on 
the Firewall screen. 


1 On the OES 2015 SP1 server you are granting access to, open the YaST Control Center and 
click Security and Users > Firewall. 


2 In the left navigation frame, click Allowed Services. 
3 In the Allowed Services drop-down list, select SSH. 
4 Click Add » Next » Accept. 
The firewall is now configured to allow SSH connections with the server. 


Adding SSH as an Allowed Service in LUM 


1 If SSH is already an allowed (PAM-enabled) service for Linux User Management on the server, 
skip to "Enabling Users for LUM" on page 95. 


or 


If SSH is not an allowed (PAM-enabled) service for Linux User Management on the server, 
continue with Step 2. 


2 On the OES 2015 SP1 server, open the YaST Control Center; then, in the Open Enterprise 
Server group, click OES Install and Configuration. 


3 Click Accept. 


4 When the Novell Open Enterprise Server Configuration screen has finished loading, click the 
Disabled link under Linux User Management. 
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The option changes to Enabled and the configuration settings appear. 

Click Linux User Management. 

Type the eDirectory Admin password in the appropriate field, then click OK » Next. 
In the list of allowed services, click sshd. 

Click Next > Next > Finish. 


on Oo UW 


Each LUM-enabled group in eDirectory, except the system-created Samba group, now shows 
SSH as an allowed service. The Samba group shows the service as not allowed (or literally 
speaking, sshd is not checked). 


Enabling Users for LUM 


There are numerous ways to enable users for LUM. 


For example, in iManager > Linux User Management there are options for enabling users (and 
choosing a Group in the process) or enabling groups (and enabling users in the process). Linux 
enabling is part of the process required for Samba access. And finally, there are also command line 
options. 


For specific instructions, refer to “Managing User and Group Objects in eDirectory” in the OES 2015 
SP1: Linux User Management Administration Guide. 


After you configure the server’s firewall to allow SSH, add SSH as an allowed service, and LUM- 
enable the eDirectory users you want to have SSH access, if those same users are not also enabled 
for Samba on the server, they now have SSH access to the server. 


On the other hand, if you have installed Samba on the server, or if you install Samba in the future, the 
users who are configured for Samba access will have SSH access disabled. 


To restore access for users impacted by Samba, see “Providing SSH Access for Samba Users” on 
page 96. 


Of course, many network administrators limit SSH access to only those who have administrative 
responsibilities. They don’t want every LUM-enabled user to have SSH access to the server. 


If you need to limit SSH access to only certain LUM-enabled users, continue with “Restricting SSH 
Access to Only Certain LUM-Enabled Users” on page 95. 


Restricting SSH Access to Only Certain LUM-Enabled Users 


SSH Access is easily restricted for one or more users by making them members of a LUM-enabled 
group and then disabling SSH access for that group. All other groups assignments that enable SSH 
access are then overridden. 
1 Open iManager in a browser using its access URL: 
http://IP_Address/iManager.html 
where /P_Addaress is the IP address of an OES 2015 SP1 server with iManager 2.7 installed. 
2 Inthe Roles and Tasks list, click Groups > Create Group. 


3 Type a group name, for example NoSSHGroup, and select a context, such as the container 
where your other Group and User objects are located. Then click OK. 


4 Inthe Roles and Tasks list, click Directory Administration > Modify Object. 
5 Browse to the group you just created and click OK. 
6 Click the Linux Profile tab. 
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7 Select the Enable Linux Profile option. 


* 


In the Add UNIX Workstation dialog box, browse to and select the UNIX Workstation objects for 
the servers you are restricting SSH access to, then click OK » OK. 


Click Apply » OK. 
In the Roles and Tasks list, click Modify Object, browse to the group again, then click OK. 
Click the Other sub-tab. 


In the Unvalued Attributes list, select uamPosixPAMServiceExcludeList, then click the 
left-arrow to move the attribute to the Valued Attributes list. 


In the Add Attribute dialog box, click the plus sign (+) next to the empty drop-down list. 
In the Add item field, type sshd, then click OK » OK. 

Click the Members tab. 

Browse to and select the User objects that shouldn't have SSH access, then click OK. 
Click Apply » OK. 


Providing SSH Access for Samba Users 


There are two options for providing SSH access to users who have been enabled for Samba access: 


You can remove the user from the server name-W-SambaUserGroup. 


IMPORTANT: This presupposes that the user is a member of a different LUM-enabled group 
that also provides access to the server. If the user was enabled for LUM only as part of a Samba 
configuration, then removing the user from the Samba group breaks access to Samba and the 
user does not have SSH access. 


You can change access for the entire Samba group by moving the 
uamPosicPAMServiceExcludeList attribute from the Valued Attributes list to the Unvalued 
Attributes list, using the instructions in "Restricting SSH Access to Only Certain LUM-Enabled 
Users" on page 95 as a general guide. 
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12.1.1 


Network Services 


The term "network services" as used in this section, refers to the protocols that provide the following: 


+ Data packet transport on the network. 
* Management of IP addresses and DNS names. 


* Time synchronization to make sure that all network devices and eDirectory replicas and 
partitions have the same time. 


* Discovery of network devices and services, such as eDirectory, printers, and so on as required 
by certain applications, clients, and other services. 
This section discusses the following: 


¢ Section 12.1, “TCP/IP,” on page 97 

* Section 12.2, “DNS and DHCP,” on page 98 

¢ Section 12.3, "Time Services," on page 100 

¢ Section 12.4, "Discovery Services,” on page 111 
¢ Section 12.5, “SLP,” on page 112 


For links to more information and tasks, see the "network protocols (http://www.novell.com/ 
documentation/oes11/index.html#cat_network-protocols-services)” links in the OES 2015 SP1 online 
documentation. 


TCP/IP 


Network nodes must support a common protocol in order to exchange packets. Transport protocols 
establish point-to-point connections so that nodes can send messages to each other and have the 
packets arrive intact and in the correct order. The transport protocol also specifies how nodes are 
identified with unique network addresses and how packets are routed to the intended receiver. 


Open Enterprise Server 2015 or later includes the standard Linux TCP/IP support on SUSE Linux 
Enterprise Server 11 SP4. 


Coexistence and Migration Issues 


Internetwork Packet Exchange (IPX) was the foundational protocol for NetWare from the 1980s until 
the release of NetWare 5.0, when support for pure TCP/IP became standard. 


To aid with migrations from NetWare to OES, coexistence between IPX and TCP/IP networks is still 
supported on NetWare, but IPX is not supported on Linux. 
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12.2 DNS and DHCP 


Domain Name Service (DNS) is the standard naming service in TCP/IP-based networks. It converts 
IP addresses, such as 192.168.1.1, to human-readable domain names, such as 
myserver.example.com, and it reverses the conversion process as required. 


The Dynamic Host Configuration Protocol (DHCP) assigns IP addresses and configuration 
parameters to hosts and network devices. 


OES 2015 SP1 includes a ported version of the NetWare DNS service, and an eDirectory integration 
with ISC DHCP as explained in the sections that follow. 


¢ Section 12.2.1, “DNS Differences Between NetWare and OES 2015 SP1,” on page 98 
¢ Section 12.2.2, “DHCP Differences Between NetWare and OES 2015 SP1,” on page 99 


12.2.1 DNS Differences Between NetWare and OES 2015 SP1 
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As you plan to upgrade from NetWare to OES 2015 SP1, consider the following differences between 
DNS on NetWare and OES 2015 SP1: 


Table 12-1 DNS: NetWare 6.5 SP8 vs. OES 2015 SP1 


Feature or Command NetWare 6.5 SP8 OES 2015 SP1 


Auditing Yes No 


Console commands: 


* Check Status * named status * rcnovell-named status 
* Force Zone-in * -zizone name N/A 

* Purge All Cache * -pa N/A 

* Screen Logging * -sS N/A 

* Start the server * named * rcnovell-named start 


or 


* /etc/init.d/novell-named 


start 
* Stop the server * named stop * rcnovell-named stop 
* Unsupported named * N/A * [-dc categories] 
command parameters e [-mstats] 


* [-nno of cpus] 


* [-qstats] 
* Zone Information * -info file name N/A 
DNSMaint Yes Yes - dns-maint 
Fault Tolerance Yes Yes 


Filenames and paths: 
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Feature or Command 


* Server binary 


NetWare 6.5 SP8 


* sys:/system/named.nlm 


OES 2015 SP1 


* /opt/novell/named/bin/ 
novell-named 


+ .db, .jnl file 


* sys:/etc/dns 


* /etc/opt/novell/named/ 
named.conf 


* Stat file, info file 


* /var/opt/novell/log/named/ 
named.run 


Journal log size 


Specify at the command prompt by 
using the jsize argument. 


Specify using Java Console, DNS 
Server Object>Advanced tab > max- 
journal-size field. 


Management 


iManager 
Command Line Interface 


Java Console 
Command Line Interface 


Unlike the Netware implementation, 
command line parameters cannot be 
passed when loading and unloading. 


SNMP Support 


12.2.2 


Yes 


No 


DHCP Differences Between NetWare and OES 2015 SP1 


As you plan to upgrade from NetWare to OES 2015 SP1, consider the following differences between 
DHCP on NetWare and OES 2015 SP1: 


Table 12-2 DHCP: NetWare 6.5 SP8 vs. OES 2015 SP1 


Feature or Command NetWare 6.5 SP8 OES 2015 SP1 
Auditing Yes No 
Filenames and paths: 
* Conf file * N/A * /etc/dhcpd.conf 
* Leases * Stored in eDirectory + /var/lib/dhcp/db/ 
dhcpd.leases 
* Log file * sys:/etc/dhcp/dhcpsrvr.log + /var/log/dhcpd.log 


* Startup log 


Management 


* N/A 


iManager 2.7 (Wizard-based) 


+ /var/log/dhcp-ldap- 
startup.log 


This is a dump of DHCP 
configurations read from 
eDirectory when the DHCP server 
starts. 


Java Console 


Unlike the NetWare implementation, 
command line parameters cannot be 
passed when loading and unloading. 


Migration 


N/A 


There is seamless migration support 
from NetWare. 
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12.3 


12.3.1 


Feature or Command NetWare 6.5 SP8 OES 2015 SP1 


Schema changes N/A There are separate locator and group 
objects for centralized management 
and easy rights management. 


SNMP Support Yes No 


Subnet naming Yes No 


Time Services 


The information in this section can help you understand your time services options as you move from 
NetWare to OES: 

¢ Section 12.3.1, “Overview of Time Synchronization," on page 100 

¢ Section 12.3.2, "Planning for Time Synchronization," on page 104 

¢ Section 12.3.3, “Coexistence and Migration of Time Synchronization Services," on page 107 

¢ Section 12.3.4, "Implementing Time Synchronization," on page 108 

¢ Section 12.3.5, "Configuring and Administering Time Synchronization," on page 110 


¢ Section 12.3.6, "Daylight Saving Time,” on page 111 


Overview of Time Synchronization 


All servers in an eDirectory tree must have their times synchronized to ensure that updates and 
changes to eDirectory objects occur in the proper order. 


eDirectory gets its time from the server operating system of the OES server where it is installed. It is, 
therefore, critical that every server in the tree has the same time. 

* "Understanding Time Synchronization Modules" on page 100 

+ “OES Servers as Time Providers" on page 102 

+ “OES Servers as Time Consumers" on page 103 


Understanding Time Synchronization Modules 


During the upgrade to OES 2015 SP1, your eDirectory tree might contain servers running different 
versions of OES, NetWare 6.5 SP8, and/or previous versions of NetWare. Therefore, you must 
understand the differences in the time synchronization modules that each operating system uses and 
how these modules can interact with each other. 

+ “OES vs. NetWare 6.5" on page 101 

+ “OES Servers Use the Network Time Protocol (NTP) to Communicate" on page 101 


¢ “Compatibility with Earlier Versions of NetWare” on page 101 
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OES vs. NetWare 6.5 


As illustrated in Figure 12-1, NetWare 6.5 can use either the Network Time Protocol (NTP) or 
Timesync modules for time synchronization. Both modules can communicate with OES by using NTP 
on port 123. However, when installing virtualized NetWare, Timesync should always be used (see 
Section 6.22.2, "Always Use Timesync Rather Than NTP,” on page 78). 


OES must use the NTP daemon (xntpd). 


Figure 12-1 Time Synchronization for Linux and NetWare 
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OES Servers Use the Network Time Protocol (NTP) to Communicate 


Because OES and NetWare servers must communicate with each other for time synchronization, and 
because OES uses only NTP for time synchronization, it follows that both OES and NetWare must 
communicate time synchronization information by using NTP time packets. 


However, this doesn't limit your options on NetWare. 


Figure 12-2 illustrates that OES and NetWare 6.5 servers can freely interchange time synchronization 
information because NetWare 6.5 includes the following: 


* ATIMESYNC NLM that both consumes and provides NTP time packets in addition to Timesync 
packets. 


* An XNTPD NLM that can provide Timesync packets in addition to offering standard NTP 
functionality. 


NOTE: Although NetWare includes two time synchronization modules, only one can be loaded at a 
time. 


Figure 12-2 NTP Packet Compatibilities with All OES Time Synchronization Modules 


NTP packets „2> 
>. 


Timesync packets 


i | Vd 
TENE 
i i Fa 


| 


Compatibility with Earlier Versions of NetWare 


Earlier versions of NetWare (version 4.2 through version 6.0) do not include an NTP time module. 
Their time synchronization options are, therefore, more limited. 
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NetWare 5.1 and 6.0 Servers 


Figure 12-3 illustrates that although NetWare 5.1 and 6.0 do not include an NTP time module, they 
can consume and deliver NTP time packets. 


Figure 12-3 NTP Compatibility of NetWare 5.1 and 6.0 
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Figure 12-4 illustrates that NetWare 4.2 and 5.0 servers can only consume and provide Timesync 
packets. 


Figure 12-4 Synchronizing Time on NetWare 5.0 and 4.2 Servers 
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Therefore, if you have NetWare 4.2 or 5.0 servers in your eDirectory tree, and you want to install an 
OES server, you must have at least one NetWare 5.1 or later server to provide a “bridge” between 
NTP and Timesync time packets. Figure 12-5 on page 103 illustrates that these earlier server 
versions can synchronize through a NetWare 6.5 server. 


IMPORTANT: As shown in Figure 12-4, we recommend that NetWare 4.2 servers not be used as a 
time source. 


OES Servers as Time Providers 


Figure 12-5 shows how OES servers can function as time providers to other OES servers and to 
NetWare servers, including NetWare 4.2 and later. 
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Figure 12-5 OES Servers as Time Providers 
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OES Servers as Time Consumers 


Figure 12-6 shows the time sources that OES servers can use for synchronizing server time. 


IMPORTANT: Notice that NetWare 4.2 is not shown as a valid time source. 
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Figure 12-6 OES servers as Time Consumers 
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123.2 Planning for Time Synchronization 


Use the information in this section to understand the basics of time synchronization planning. 


* “NetWork Size Determines the Level of Planning Required” on page 104 
* “Choose Timesync for Virtualized NetWare Only" on page 105 
* "Planning a Time Synchronization Hierarchy before Installing OES” on page 105 
For more detailed planning information, refer to the following resources: 
* "How Timesync Works" in the NW 6.5 SP8: Network Time Synchronization Administration Guide 
* "Network Time Protocol" in the NW 6.5 SP8: NTP Administration Guide 
+ NTP information on the Web (http://www.cis.udel.edu/-mills/ntp.html) 


NetWork Size Determines the Level of Planning Required 


The level of time synchronization planning required for your network is largely dictated by how many 
servers you have and where they are located, as explained in the following sections. 


* "Time Synchronization for Trees with Fewer Than Thirty Servers" on page 105 
¢ "Time Synchronization for Trees with More Than Thirty Servers" on page 105 


* "Time Synchronization across Geographical Boundaries" on page 105 
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Time Synchronization for Trees with Fewer Than Thirty Servers 


If your tree will have fewer than thirty servers, the default installation settings for time synchronization 
should be sufficient for all of the servers except the first server installed in the tree. 


You should configure the first server in the tree to obtain time from one or more time sources that are 
external to the tree. (See Step 1 in "Planning a Time Synchronization Hierarchy before Installing 
OES" on page 105.) 


All other servers should point to the first server in the tree for their time synchronization needs. 


Time Synchronization for Trees with More Than Thirty Servers 


If your tree will have more than thirty servers, you need to plan and configure your servers with time 
synchronization roles that match your network architecture and time synchronization strategy. 
Example roles might include the following: 


* Servers that receive time from external time sources and send packets to other servers further 
down in the hierarchy 


* Servers that communicate with other servers in peer-to-peer relationships to ensure that they are 
synchronized 


Basic planning steps are summarized in "Planning a Time Synchronization Hierarchy before Installing 
OES” on page 105. 


Refer to the following sources for additional help in planning time server roles: 
+ "Configuring Timesync on Servers" in the NW 6.5 SP8: Network Time Synchronization 
Administration Guide 
* "Modes of Time Synchronization" in the NW 6.5 SP8: NTP Administration Guide 
+ NTP information on the Web (http:/Awww.cis.udel.edu/~mills/ntp.html) 


Time Synchronization across Geographical Boundaries 


If the servers in the tree will reside at multiple geographic sites, you need to plan how to synchronize 
time for the entire network while minimizing network traffic. For more information, see "Wide Area 
Configuration" in the NW 6.5 SP8: NTP Administration Guide. 


Choose Timesync for Virtualized NetWare Only 


When you install a virtualized NetWare 6.5 server, you should always use Timesync and configure it 
to communicate using NTP. For more information, see "You Must Use Timesync for Time 
Synchronization" in the OES 2015 SP1: Installation Guide. 


The dialog box that lets you choose between Timesync and NTP is available as an advanced option 
in the Time Zone panel during the NetWare installation. Choosing between Timesync and NTP is 
documented in "Setting the Server Time Zone and Time Synchronization Method" in the NW65 SP8: 
Installation Guide. 


Planning a Time Synchronization Hierarchy before Installing OES 


The obvious goal for time synchronization is that all the network servers (and workstations, if desired) 
have the same time. This is best accomplished by planning a time synchronization hierarchy before 
installing the first OES server, then configuring each server at install time so that you form a hierarchy 
similar to the one outlined in Figure 12-7. 
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Figure 12-7 A Basic Time Synchronization Hierarchy 
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As you plan your hierarchy, do the following: 
1 Identify at least two authoritative external NTP time sources for the top positions in your 
hierarchy. 


* |f your network already has an NTP server hierarchy in place, identify the IP address of an 
appropriate time server. This might be internal to your network, but it should be external to 
the eDirectory tree and it should ultimately obtain time from a public NTP server. 


* |f your network doesn't currently employ time synchronization, refer to the list of public NTP 
servers published on the ntp.org Web site (http://support.ntp.org/bin/view/Servers/ 
WebHome) and identify a time server you can use. 


2 Plan which servers will receive time from the external sources and plan to install these servers 
first. 


3 Map the position for each Linux server in your tree, including its time sources and the servers it 
will provide time for. 


4 Map the position for each NetWare server in your tree: 
4a Include the server's time sources and the servers it will provide time for. 


4b If your network currently has only NetWare 4.2 or 5.0 servers, be sure to plan for their time 
synchronization needs by including at least one newer NetWare server in the tree and 
configuring the older servers to use the newer server as their time source. (See "NetWare 
5.0 and 4.2 Servers" on page 102.) 


5 Be sure that each server in the hierarchy is configured to receive time from at least two sources. 


6 (Conditional) If your network spans geographic locations, plan the connections for time-related 
traffic on the network and especially across WANs. 


For more information, see "Wide Area Configuration" in the NW 6.5 SP8: NTP Administration 
Guide. 
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12.3.3 


For more planning information, see the following documentation: 


* NW 6.5 SP8: Network Time Synchronization Administration Guide 
* NW 6.5 SP8: NTP Administration Guide 


* NTP information found on the OES 2015 SP1 server in /usr/share/doc/packages/xntp and on the 
Web (http://www.cis.udel.edu/~mills/ntp.html) 


Coexistence and Migration of Time Synchronization 
Services 


The time synchronization modules in OES have been designed to ensure that new OES servers can 
be introduced into an existing network environment without disrupting any of the products and 
services that are in place. 


This section discusses the issues involved in the coexistence and migration of time synchronization in 
OES in the following sections: 


+ “Coexistence” on page 107 
* "Upgrading from NetWare to OES 2015 SP1” on page 108 


Coexistence 


This section provides information regarding the coexistence of the OES time synchronization 
modules with existing NetWare or Linux networks, and with previous versions of the TIMESYNC 
NLM. This information can help you confidently install new OES servers into your current network. 


+ "Compatibility" on page 107 
* "Coexistence Issues" on page 108 
Compatibility 


The following table summarizes the compatibility of OES time synchronization modules with other 
time synchronization modules and eDirectory. These compatibilities are illustrated in Figure 12-5 on 
page 103 and Figure 12-6 on page 104. 


Table 12-3 Time Synchronization Compatibility 


Module Compatibility 
TIMESYNC NLM (NetWare) Can consume time from 


* All previous versions of Timesync. However, the NetWare 4.2 
TIMESYNC NLM should not be used as a time source. 


* Any TIMESYNC or NTP daemon. 
Can provide time to 


* All previous versions of Timesync. 


* Any TIMESYNC or NTP daemon. 


Network Services 107 


12.3.4 


Module Compatibility 
XNTPD NLM (NetWare) Can consume time from 
* Any NTP daemon. 
Can provide time to 


* All previous versions of Timesync. 


* Any NTP daemon. 
xntpd daemon (SLES 11) Can consume time from 
* Any NTP daemon. 
Can provide time to 
* Any NTP daemon. 
eDirectory eDirectory gets its time synchronization information from the host 
OS (Linux or NetWare), not from the time synchronization modules. 
Coexistence Issues 


If you have NetWare servers earlier than version 5.1, you need to install at least one later version 
NetWare server to bridge between the TIMESYNC NLM on the earlier server and the OES servers 
you have on your network. This is because the earlier versions of Timesync can't consume or provide 
NTP time packets and the xntpd daemon on Linux can't provide or consume Timesync packets. 


Fortunately, the TIMESYNC NLM in NetWare 5.1 and later can both consume and provide Timesync 
packets. And the XNTPD NLM can provide Timesync packets when required. 


This is explained in "Compatibility with Earlier Versions of NetWare" on page 101. 


Upgrading from NetWare to OES 2015 SP1 


The OES 2015 SP1 Migration Tool can migrate time synchronization services from NetWare to Linux. 
For more information, see "Migrating NTP to OES 2015 SP1" in the OES 2015 SP1: Migration Tool 
Administration Guide. 


Implementing Time Synchronization 


As you plan to implement your time synchronization hierarchy, you should know how the NetWare 
and OES 2015 SP1 product installations configure time synchronization on the network. Both installs 
look at whether you are creating a new tree or installing into an existing tree. 

* "New Tree" on page 109 

* "Existing Tree" on page 109 
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New Tree 


By default, both the OES 2015 SP1 and the NetWare 6.5 SP8 installs configure the first server in the 
tree to use its internal (BIOS) clock as the authoritative time source for the tree. 


Because BIOS clocks can fail over time, you should always specify an external, reliable NTP time 
source for the first server in a tree. For help finding a reliable NTP time source, see the NTP Server 
Lists (http://support.ntp.org/bin/view/Servers/WebHome) on the Web. 


+ “OES 2015 SP1” on page 109 
* “NetWare 6.5 SP8” on page 109 


OES 2015 SP1 


When you configure your eDirectory installation, the OES 2015 SP1 install prompts you for the IP 
address or DNS name of an NTP v3-compatible time server. 


If you are installing the first server in a new eDirectory tree, you have two choices: 


* You can enter the IP address or DNS name of an authoritative NTP time source (recommended). 


* You can leave the field displaying Local Time, so the server is configured to use its BIOS clock 
as the authoritative time source. 


IMPORTANT: We do not recommend this second option because BIOS clocks can fail over 
time, causing serious problems for eDirectory. 


NetWare 6.5 SP8 


By default, the NetWare install automatically configures the TIMESYNC NLM to use the server's 
BIOS clock. As indicated earlier, this default behavior is not recommended for production networks. 
You should, therefore, manually configure time synchronization (either Timesync or NTP) while 
installing each NetWare server. 


Manual time synchronization configuration is accessed at install time from the Time Zone dialog box 
by clicking the Advanced button as outlined in "Choose Timesync for Virtualized NetWare Only" on 
page 105 and as fully explained in "Setting the Server Time Zone and Time Synchronization Method" 
in the NW65 SP8: Installation Guide. 


Existing Tree 


When a server joins an existing eDirectory tree, both OES installations do approximately the same 
thing. 


+ “OES 2015 SP1” on page 110 
* “NetWare 6.5 SP8” on page 110 
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OES 2015 SP1 


If you are installing into an existing tree, the OES 2015 SP1 install proposes to use the IP address of 
the eDirectory server (either NetWare or Linux) as the NTP time source. This default should be 
sufficient unless one of the following is true: 


* The server referenced is a NetWare 5.0 or earlier server, in which case you need to identify and 
specify the address of another server in the tree that is running either a later version of NetWare 
or any version of OES. 


* You will have more than 30 servers in your tree, in which case you need to configure the server 
to fit in to your planned time synchronization hierarchy. For more information, see "Planning a 
Time Synchronization Hierarchy before Installing OES" on page 105. 


The OES 2015 SP1 install activates the xntp daemon and configures it to synchronize server time 
with the specified NTP time source. After the install finishes, you can configure the daemon to work 
with additional time sources to ensure fault tolerance. For more information, see "Changing Time 
Synchronization Settings on a SLES 11 Server" on page 110. 


NetWare 6.5 SP8 


If you are installing into an existing tree, the NetWare 6.5 SP8 install first checks to see whether you 
manually configured either NTP or Timesync time synchronization sources while setting the server 
Time Zone (see "Setting the Server Time Zone and Time Synchronization Method" in the NW65 SP8: 
Installation Guide). 


If you will have more than 30 servers in your tree, you should have developed a time synchronization 
plan (see "Planning a Time Synchronization Hierarchy before Installing OES" on page 105) and used 
the Time Zone panel to configure your server according to the plan. 


If you haven't manually configured time synchronization sources for the server (for example, if your 
tree has fewer than 30 servers), the install automatically configures the Timesync NLM to point to the 
IP address of the server with a master replica of the tree's [ROOT] partition. 


Configuring and Administering Time Synchronization 


As your network changes, you will probably need to adjust the time synchronization settings on your 
servers. 
+ "Changing Time Synchronization Settings on a SLES 11 Server" on page 110 


¢ "Changing Time Synchronization Settings on a NetWare Server" on page 111 


Changing Time Synchronization Settings on a SLES 11 Server 


This method works both in the GUI and at the command prompt and is the most reliable method for 
ensuring a successful NTP implementation. 


1 Launch YaST on your SLES 11 server by either navigating to the application on the desktop or 
typing yast at the command prompt. 
2 Click Network Services » NTP Configuration. 


3 In the Advanced NTP Configuration dialog box, modify the NTP time settings as your needs 
require. 
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12.3.6 


12.4 


12.4.1 


Changing Time Synchronization Settings on a NetWare Server 


Time synchronization settings and their modification possibilities are documented in the following 
administration guides: 


¢ Timesync: NW 6.5 SP8: Network Time Synchronization Administration Guide 
* NTP: NW 6.5 SP8: NTP Administration Guide 


Daylight Saving Time 


For information about daylight saving time (DST), go to the Novell Support Knowledgebase (http:// 
www.novell.com/support/kb/) and search for Daylight Saving Time. 


Discovery Services 


Various discovery mechanisms are usually available on an OES network. 


* DNS/DHCP 
* Directory services 
* Local host configuration files 


* Service Location Protocol (SLP services) 


NOTE: NetWare 3 and 4 used the IPX-based Service Advertising Protocol (SAP) as the 
discovery mechanism. All the servers advertised their services automatically. If a server went 
offline, the SAP information on the network was dynamically refreshed. 


Starting with NetWare 5 and pure TCP/IP, the Service Location Protocol was adopted as the 
default, though optional, discovery mechanism. SLP was chosen because it was the TCP/IP- 
based protocol most like SAP in its automatic nature and dynamic refresh capabilities. 


For more information, see Section 12.5, “SLP,” on page 112. 


* Universal Description, Discovery, and Integration (UDDI) server 


Some systems are designed to leverage only a single discovery technology. Others choose among 
the various providers. And some use different technologies in combination with each other. 


Novell SLP and OpenSLP 


NetWare 3 and 4 used the IPX-based Service Advertising Protocol (SAP) as the discovery 
mechanism. All the servers advertised their services automatically. If a server went offline, the SAP 
information on the network was dynamically refreshed. 


Starting with NetWare 5 and pure TCP/IP, the Service Location Protocol was adopted as the default, 
though optional, discovery mechanism. SLP was chosen because it was the TCP/IP-based protocol 
most like SAP in its automatic nature and dynamic refresh capabilities. 


For more information, see Section 12.5, “SLP,” on page 112. 
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12.5.1 


SLP 


The OpenSLP services on OES 2015 SP1 are compatible and comparable with NetWare SLP 
services. 


This section discusses the following topics: 


¢ Section 12.5.1, “Overview,” on page 112 

¢ Section 12.5.2, “Comparing Novell SLP and OpenSLP,” on page 114 

¢ Section 12.5.3, “Setting Up OpenSLP on OES 2015 SP1 Networks," on page 115 
¢ Section 12.5.4, "Using Novell SLP on OES 2015 SP1 Networks," on page 120 

¢ Section 12.5.5, "TIDs and Other Help,” on page 124 


Overview 


The Service Location Protocol (SLP) was developed so that clients and other software modules can 
dynamically discover and use services on the network without knowing the IP address or the 
hostname of the server offering the service. 

+ "Why SLP Is Needed" on page 112 

* "About the Three SLP Agents and Their Roles" on page 112 

+ “Overcoming the Subnet Limitation" on page 113 

* "An eDirectory Example" on page 113 


+ "What Happens When a DA Goes Down?" on page 113 


Why SLP Is Needed 


NetWare: Although many other applications and server types rely on SLP for service discovery, 
NetWare services are actually integrated with eDirectory, and if eDirectory is configured correctly, the 
services work without SLP. However, SLP is automatically provided on NetWare for other services 
that might be installed. 


OES: On the other hand, for OES services to work, the server must either: 
* Have an eDirectory replica installed. 


This is not automatic after the third server installed in a tree, nor is having more than three to five 
replicas on servers in the tree recommended. 
* Have eDirectory registered with the OpenSLP service running on the server. 


This requires SLP configuration either during the OES 2015 SP1 installation or manually. 


About the Three SLP Agents and Their Roles 


Three software "agents" provide the infrastructure for SLP-based service discovery: 
* Service Agents (SAs): Are a required component of any SLP infrastructure. They act on behalf 
of a network service that is running on a server by advertising that the service is available. 


* User Agents (UAs): Are also required. They act on behalf of clients or other software modules 
that need network services by searching for the needed services. 
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* Directory Agents (DAs): Are technically optional, but they are used in most SLP infrastructures. 
They collect service information from Service Agents so that User Agents can more easily locate 
the services. DAs are like a phone book directory listing of services on the network. 


DAs are not needed when all of the SAs and UAs are on the same subnet. This is because the 
UAs and SAs can find each other within the subnet using multicast packets, provided that there 
are no firewalls that are set to block multicast traffic. 


Overcoming the Subnet Limitation 


Novell recommends against routing multicast packets across subnet boundaries, and most network 
configurations conform with that recommendation. Therefore, when SAs and UAs are on different 
subnets, they need an alternative to multicasting for advertizing and locating services on the other 
subnets. 


Network administrators use DAs to solve this problem by setting up organizational or geographical 
DAs and then configuring the SAs and UAs within the organization or geographical area to use them. 
Many administrators further subdivide the DA workload by defining multiple SLP scopes based on 
different kinds of network services, and then configuring the SAs and UAs to communicate with the 
DAs servicing the scope that pertains to them. 


An eDirectory Example 


When you configure eDirectory during an OES server installation, you have the option of specifying 
one or more SLP DAs for the server to communicate with. Each time eDirectory starts and every hour 
thereafter, the server's SA will send a unicast packet to the server's assigned DAs, advertising that its 
eDirectory services are available. 


IMPORTANT: Prior to eDirectory 8.8.2, the eDirectory SA advertised service availability every 10 
minutes by default. Starting with eDirectory 8.8.2, the refresh interval changed to one hour. This has 
caused some confusion for network administrators who couldn't figure out why it took so long for 
eDirectory to register as a service 


For information on how to set the refresh interval to a smaller value, see TID 7001449 (http:// 
www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=7001449&sliceld=2&docTypelD=DT_TID_1 1 
&dialoglID=104660609&stateld=0%200%20209665064) in the Novell Support Knowledgebase. 


What Happens When a DA Goes Down? 


As you can imagine, a directory agent in a large organization can accumulate many service listings 
after it has been running for a while. Unfortunately, because DAs are inherently cache-only 
repositories, if they go down for some reason, when they come back up their list of services is initially 
blank. 


Novell SLP solved this problem on NetWare 5.x and later through eDirectory Modified Event 
notifications. These notifications keep all of the NetWare DA's that are servicing the same scope in 
sync with each other. After going down and coming back up, a NetWare DA can quickly recover its 
directory listings. 


OpenSLP DA's, on the other hand, have historically been completely independent from each other. 
Because they are not eDirectory-aware, they have had no means of recovering the directory listings 
they had prior to going down. 


This changed, beginning in OES 2 SP3. 
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OpenSLP DAs can now 


* Retrieve and/or push service information to and/or from other DAs. For more information, see 
"Synchronizing Data Between OpenSLP DAs and/or Novell SLP DAs" on page 117. 


* Back up their service registrations so that when the DA service is started up it can read the 
backup file and pre-populate its cache. For more information, see "Backing Up Registrations and 
Managing Persistence" on page 118. 


These changes provide, in effect, the same type of DA to DA communication for OES that has 
traditionally been available only on NetWare. 


125.2 Comparing Novell SLP and OpenSLP 
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Table 12-4 SLP Solutions 


Platform NetWare OES 2015 SP1 

SLP Solution Novell SLP OpenSLP 

About the The Novell version of SLP adapted OpenSLP is an implementation of 

Solution portions of the SLP standard to various IETF specifications, 
provide a more robust service including RFC 2614 (SLP version 
advertising environment. 2.0). It is the default SLP service 


installed on SLES 11. 
Novell SLP remains the default 


discovery mechanism for NetWare In OES 2015 SP1, OpenSLP is 


6.5 SP8 servers. However, all available for those applications that 
NetWare service components that require it. The default discovery 
engage in discovery, including mechanism is actually DNS, but SLP 
Novell Client software, can use must be present for any applications 
alternative mechanisms suchas that require it, especially in those 
DNS, eDirectory, or local host cases where the OES 2015 SP1 
configuration files. server is the fourth or later server 


added to a tree and doesn't have an 
eDirectory replica automatically 
installed. 
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12.5.3 


Platform 


Differences 


Compatibility 


Documentati 
on 


Setting Up OpenSLP on OES 2015 SP1 Networks 


SLP services are always installed as part of both NetWare and SLES 11 SP4 (the underlying OES 
2015 SP1 platform). On NetWare and on OES, SLP services run automatically in multicast mode. 


NetWare 


Novell SLP directory agents (DAs) 
store service registrations for their 
SLP scope in eDirectory. 


As a new service registration is 
stored in eDirectory, other DAs 
assigned to the same scope are 
notified so that they can refresh 
their caches with the latest service 
information. 


Also, when a Novell SLP DA starts 
up, it immediately populates its 
cache with the latest service 
information stored in eDirectory. 


NOTE: Novell SLP DAs do not 
directly share information with 
each other as many administrators 
have assumed. But they do 
maintain well synchronized caches 
through eDirectory as described 
above. 


Novell SLP user agents (UAs) or 
service agents (SAs) can access 
both Novell SLP DAs and 
OpenSLP DAs. 


Setting Up SLP on NetWare 
(https://www.netiq.com/ 
documentation/edir88/edir88/ 
?page-/documentation/edir88/ 
edir88/data/ba6406j.html). 


OES 2015 SP1 


OpenSLP directory agents (DAs) 
are able to share service 
registrations as described in 
"Synchronizing Data Between 
OpenSLP DAs and/or Novell SLP 
DAs" on page 117. 


OpenSLP is also capable of 
ensuring data persistence when 
DAs go down, as explained in 
"Backing Up Registrations and 
Managing Persistence" on 
page 118. 


OpenSLP-based user agents or 
service agents can access both 


Novell SLP DAs and OpenSLP DAs. 


"Configuring OpenSLP for 
eDirectory” in the NetIQ eDirectory 
8.8 SP8 Administration Guide. 


Setting up directory agents and multiple scopes, etc. requires a manual configuration of SLP, either 
during the installation or by modifying the slpd.conf file afterward. 


* "When Is OpenSLP Required?" on page 116 
+ "Setting Up an OpenSLP DA Server” on page 116 


* “Synchronizing Data Between OpenSLP DAs and/or Novell SLP DAs” on page 117 


* “Backing Up Registrations and Managing Persistence” on page 118 


+ “Configuring OES 2015 SP1 Servers to Access the OpenSLP DA” on page 118 


+ "Configuring NetWare Servers to Use the OpenSLP Service" on page 119 
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When Is OpenSLP Required? 


The OES install automatically starts OpenSLP on your OES 2015 SP1 server in case any of the 
following applies: 

* You install more than three servers into a new tree 

* You create a new eDirectory partition on an OES 2015 SP1 server. 


* You either don't have an existing Novell SLP service, or you don't want to continue using Novell 
SLP. 


IMPORTANT: If you need to set up OpenSLP in more than multicast mode for the reasons above, it 
is most convenient if you do it before you install the fourth server in your tree or partition. That way 
you can point to the SLP service during the installation. Setting up SLP services on every OES 2015 
SP1 server is recommended. 


Setting Up an OpenSLP DA Server 


The default SLP configuration in the YaST-based install doesn't include having a Directory Agent. 
This approach is far less robust, requires multicasting, and involves disabling the firewall. 


If you need OpenSLP and you don't already have an OpenSLP Directory Agent (DA) set up on your 
network, for simplicity's sake we recommend that you set up the first OES 2015 SP1 server in your 
tree as an OpenSLP DA. The simplest way to do this is during server installation by selecting the 
Configure as Directory Agent option in the YaST-based installation. 


After creating the DA, you can then configure all subsequently installed servers to either point to that 
DA or to other DAs you create later. 


To set up an OpenSLP DA on an existing OES 2015 SP1 server, do the following. 

1 On the OES 2015 SP1 server that will become the DA, open the /etc/slp.conf file in a text 
editor. 

2 In slp.conf, remove the semicolon [;]) from the beginning of the following line: 
;net.slp.isDA - true 
so that it reads 
net.slp.isDA - true 

3 Find the following line: 


;net.slp.useScopes = myScopei, myScope2, myScope3 


IMPORTANT: The example in the configuration file is misleading because the spaces after each 
comma are not ignored as one might expect them to be. 


Therefore, the scope names created or configured by the statement after the first comma 
actually have leading spaces in them. For example, the first scope name is “myScope1” but the 
scope names that follow it all have leading spaces, “ myScope2", " myScope3" and so on. This is 
a problem, especially if one of the later names becomes the first name in a subsequent SLP 
configuration and the leading space is ignored. 


If you use the scopes given in the example, remove the spaces between the entries. 


4 Modify the line by removing the semicolon and typing the name of the scope you want this DA to 
use to provide service information on the network. For example, you might change the line as 
follows: 
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net.slp.useScopes - Directory 


IMPORTANT: Although SLP provides a default scope if no scope is specified, it is always good 
practice to define one or more scopes by configuring the net.slp.useScopes parameter in 
slp.conf. 


Scopes group and organize the services on your network into logical categories. For example, 
the services that the Accounting group needs might be grouped into an Accounting scope. 


More information about scope planning is available on the OpenSLP Web site (http:// 
www.openslp.org/). 


When no scope is specified, all services are registered in a scope named Default. 


5 Configure the firewall on the DA server to allow SLP daemon traffic: 
5a In the YaST Control Center, click Security and Users > Firewall. 
5b In the left navigation frame, click Allowed Services. 
5c Click the Services to Allow drop-down list and select SLP Daemon. 
5d Click Add > Next. 
5e Click Accept. 
6 Atthe command prompt, enter the following command to restart the SLP daemon: 
rcslpd restart 


7 (Conditional) If you are doing this after installing OES 2015 SP1 and eDirectory, you must also 
restart eDirectory by entering the following command: 


rcndsd restart 
8 Continue with the following sections that apply to your situation: 
* Synchronizing Data Between OpenSLP DAs and/or Novell SLP DAs (page 117) 
* Backing Up Registrations and Managing Persistence (page 118) 
* Configuring OES 2015 SP1 Servers to Access the OpenSLP DA (page 118) 
* Configuring NetWare Servers to Use the OpenSLP Service (page 119) 


Synchronizing Data Between OpenSLP DAs and/or Novell SLP DAs 


If you didn't set up DA synchronization during server installation, you can set it up later by using the 
following parameters in the slp.conf file: 


net.slp.dasyncreg - true/false 
slp.DAaddresses - IP address 1,IP address 2 


If the net. s1p.dasyncreg parameter value is set to true, then synchronization is achieved by the 
DA pushing or pulling SLP registrations from the DAs listed for the slp.DAaddresses parameter, as 
follows: 


1. When the DA starts up, it pulls the registration information from all of the server DAs listed in the 
slp.DAaddresses parameter, including any Novell SLP DAs listed. 


2. When the DA receives a service registration, it forwards the information to the OpenSLP DAs 
that are listed. 


IMPORTANT: Service registrations cannot be pushed to Novell SLP DA's. 
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Backing Up Registrations and Managing Persistence 


If you didn't set up registration back-up during server installation, you can set it up later by using the 
following parameters in the slp.conf file: 


net.slp.isDABackup - true/false 
net.slp.DABackupInterval - time in seconds 


If the net. s1p.isDABackup parameter is set to true, service registrations are backed up in the / 
etc/slp.reg.d/slpd/DABackup file at the interval specified for the net. s1p.DABackupInterval 
parameter. By default, the interval is 900 seconds (15 minutes). 


Configuring OES 2015 SP1 Servers to Access the OpenSLP DA 


If you created the OpenSLP DA on an OES 2015 SP1 server installed in your tree, then SLP is 
properly configured on that server and these instructions do not apply to it. 


For all other OES 2015 SP1 servers installed in your eDirectory tree, you should complete one of the 
following procedures as it applies to your situation: 

+ "Configuring for DA Access During the OES 2015 SP1 Installation" on page 118 

¢ "Configuring for DA Access Before or After Installing OES 2015 SP1" on page 118 


Configuring for DA Access During the OES 2015 SP1 Installation 


As you install OES 2015 SP1 by using the instructions in the “NetIQ eDirectory Services" section of 
the OES 2015 SP1: Installation Guide, do the following: 


1 When you reach the "eDirectory Configuration - NTP and SLP" section of the installation, select 
Configure SLP to Use an Existing Directory Agent. 


The first option, Use Multicast, requires that you disable the firewall on the server. Disabling the 
firewall is always discouraged. 


2 In the Service Location Protocol Scopes field, specify the scope you defined in Step 4 on 
page 116. You can also list additional scopes, separated by commas (no spaces). 


For example, you might type Directory in the field if that is the scope name you assigned to the 
DA you created. 


3 In the Configured SLP Directory Agent field, type the IP address of the DA server you defined in 
"Setting Up an OpenSLP DA Server" on page 116. You can also list additional DA addresses, 
separated by commas. 


4 Return to the "NetlO Modular Authentication Services" instructions in the OES 2015 SP1: 
Installation Guide. 


Configuring for DA Access Before or After Installing OES 2015 SP1 


Whether you configure DA access before installing OES 2015 SP1 on a SLES 11 SP4 server or after 
a simultaneous install of SLES 11 SP4 and OES 2015 SP1, the manual DA configuration process is 
the same. 

1 Open /etc/slp.conf in a text editor. 

2 Find the following line: 


;net.slp.useScopes = myScopei, myScope2, myScope3 
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IMPORTANT: The example in the configuration file is misleading because the spaces after each 
comma are not ignored as one might expect them to be. 


Therefore, the scope names created or configured by the statement after the first comma 
actually have leading spaces in them. For example, the first scope name is “myScope1” but the 
scope names that follow it all have leading spaces, “ myScope2", " myScope3" and so on. This is 
a problem, especially if one of the later names becomes the first name in a subsequent SLP 
configuration and the leading space is ignored. 


If you use the scopes given in the example for some reason, remove the spaces between the 
entries. 


3 Modify the line by removing the semicolon and typing the name or names of the scopes you 
want this server to have access to. Be sure to include the scope you defined in Step 4 on 
page 116. 


For example, you might change the line as follows: 
net.slp.useScopes - Directory 

4 Find the following line: 
;net.slp.DAAddresses = myDa1,myDa2,myDa3 


5 Modify the line by removing the semicolon and typing the actual IP address of the OpenSLP DA 
you defined in "Setting Up an OpenSLP DA Server" on page 116. 


net.slp.DAAddresses - IP Address 
6 Save the file and close it. 


7 Atthe Linux command prompt, enter the following to restart the SLP daemon and reset its 
configuration: 


rcslpd restart 


Configuring NetWare Servers to Use the OpenSLP Service 


IMPORTANT: NetWare uses Novell SLP by default and will configure a server for that service if 
possible. 


Complete one of the following as it applies to your situation: 


+ "Configuring for DA Access During the NetWare Server Installation” on page 119 


+ "Configuring for DA Access After Installing the NetWare Server" on page 120 


Configuring for DA Access During the NetWare Server Installation 


In the dialog box where you set up IP addresses for network boards, click Advanced. 
Click the SLP tab. 
Specify the IP address of the OES 2015 SP1 DA servers—up to three. 


Type the list of scopes covered by the configured DAs that you want the NetWare server to have 
access to. 


Bh WN HM 


IMPORTANT: We recommend you do not configure the server to use multicast because that 
necessitates disabling firewalls, which is never recommended. 


5 Click OK. 
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Configuring for DA Access After Installing the NetWare Server 


1 Using a text editor, edit the SYS: ETC/slp.cfg file on the NetWare server and add the following 
line for each DA server you want the NetWare server to have access to: 


DA IPV4, IP_Address1 
DA IPV4, IP Address2 
where /P_Adadressx is the IP address of an OES 2015 SP1 DA server. 
2 Save the file and close it. 
3 Atthe NetWare console prompt, specify the scopes you want the NetWare server to have access 
to, write the SLP cache to the registry, and restart the SLP service: 


set slp scope list = scope1, scope2,... 
flush cdbe 
set slp reset - on 


4 Verify that SLP is functioning correctly by entering the following command: 


display slp services 


125.4 Using Novell SLP on OES 2015 SP1 Networks 


If you have a NetWare tree, you automatically have Novell SLP on your network and you can 
continue to use it as the SLP service during the upgrade to OES 2015 SP1 until you are ready to 
switch to OpenSLP. 


This section discusses the following: 


+ “NetWare Is Configured with Novell SLP By Default” on page 120 
¢ "Configuring OES 2015 SP1 Servers to Access the Novell SLP DA" on page 120 
+ "Checking the Status of Novell SLP Services" on page 123 


NetWare Is Configured with Novell SLP By Default 


When you install NetWare, if you don't specify an alternate SLP configuration, the server is 
automatically configured to use Novell SLP in a way that is sufficient for most networks. 


Configuring OES 2015 SP1 Servers to Access the Novell SLP DA 


For each of the OES 2015 servers installed in your eDirectory tree, you should complete one of the 
following procedures as it applies to your situation: 


+ "Configuring for DA Access During the OES 2015 SP1 Installation" on page 120 
+ "Configuring for DA Access Before or After Installing the OES 2015 SP1 Server" on page 121 


Configuring for DA Access During the OES 2015 SP1 Installation 


As you install OES 2015 SP1, in the "NetlO eDirectory Services" section of the OES 2015 SP1: 
Installation Guide, do the following: 


1 When you reach the SLP section of the installation, select Configure SLP to Use an Existing 
Directory Agent. 


The first option, Use Multicast, requires that you disable the firewall on the server. Disabling the 
firewall is always discouraged. 
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2 In the Service Location Protocol Scopes field, specify one or more appropriate scopes that are 
defined on your network. 


If you aren't sure about the exact scope names, you can view the SLP configuration of a 
NetWare server on the same network segment. Log into Novell Remote Manager on the server 
and click Manage Applications » SLP. 


You can list multiple scopes, separated by commas (no spaces). 


For example, you might type Directory in the field. 
3 In the Configured SLP Directory Agent field, type the IP address of an appropriate DA server. 
You can use Novell Remote Manager on a NetWare server if you aren't sure which address to 


use. 


You can also list additional DA addresses, separated by commas. 
4 Return to the “NetIQ eDirectory Services" instructions in the OES 2015 SP1: Installation Guide. 


Configuring for DA Access Before or After Installing the OES 2015 SP1 Server 


Whether you configure DA access before installing OES 2015 SP1 on a SLES 11 SP4 server or after 
a simultaneous install of SLES 11 SPA and OES 2015 SP1, the manual DA configuration process is 


the same. 


1 Open /etc/slp.conf in a text editor. 
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# OpenSLP configuration file 
# 


# Format and contents conform to specification in IETF RFC 2614 so the 

# comments use the Language of the RFC. In OpenSLP, SLPD operates as an SA 

# and a DA. The SLP UA functionality is encapsulated by SLPLIB. 

# 

FARE AE 


# This option is a comma delimited list of strings indicating the only scopes | 
# a UA or SA is allowed when making requests or registering or the scopes a 
# DA must support. (default value is "DEFAULT") 


|;net.slp.useScopes = myScopel, myScope2, myScope3 


# Allows administrator to force UA and SA agents to use specific DAs. If 
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# this setting is not used dynamic DA discovery will be used to determine 
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2 Find the following line: 


;net.slp.useScopes 
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= myScope1, myScope2, myScope3 
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IMPORTANT: The example in the configuration file is misleading because the spaces after each 
comma are not ignored as one might expect them to be. 


Therefore, the scope names created or configured by the statement after the first comma 
actually have leading spaces in them. For example, the first scope name is “myScope1” but the 
scope names that follow it all have leading spaces, “ myScope2", " myScope3" and so on. This is 
a problem, especially if one of the later names becomes the first name in a subsequent SLP 
configuration and the leading space is ignored. 


If you use the scope names given in the example, remove the spaces between the entries. 


3 Modify the line by removing the semicolon and typing the name or names of the scopes you 
want this server to have access to. 


If you aren't sure about the exact scope names, you can view the SLP configuration of a 
NetWare server on the same network segment. Log into Novell Remote Manager on the server 
and click Manage Applications » SLP. 


You can list multiple scopes, separated by commas (no spaces). 
For example, you might change the line as follows: 


net.slp.useScopes - Directory 


*sip.conf (/etc) - gedit 
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net.slp.useScopes = Directory 
# Allows administrator to force UA and SA agents to use specific DAs. If d 


# this setting is not used dynamic DA discovery will be used to determine 
# which DAs to use. (Default is to use dynamic DA discovery) 
;net.slp.DAAddresses - myDal,myDa2,myDa3 


3 Enables slpd to function as a DA. Only a very few DAs should exist. It 
# is suggested that the administrator read the OpenSLP users guide before 
# enabling this setting. Default is false. Uncomment the line below to 
# enable DA operation. 

;net.slp.isDA = true 


# A 32 bit integer giving the number of seconds for the DA heartbeat. 
# Default is 3 hours (10800 seconds). This property corresponds to 
# the nrotocol specification narameter CONFTG DA RFAT [7]. Tanored b 
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4 Find the following line: 
;net.slp.DAAddresses = myDai,myDa2,myDa3 


5 Modify the line by removing the semicolon and typing the actual IP address of the Novell SLP DA 
(using Novell Remote Manager if necessary). 
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net.slp.DAAddresses - IP Address 


*sip.conf (/etc) - gedit 
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# DA must support. (default value is "DEFAULT") 


net.slp.useScopes = Directory 


# Allows administrator to force UA and SA agents to use specific DAs. If 
# this setting is not used dynamic DA discovery will be used to determine 
# which DAs to use. (Default 1s to use dynamic DA discovery) 


net.slp.DAAddresses = 192.168.1.100 


# Enables slpd to function as a DA. Only a very few DAs should exist. It 
# 1s suggested that the administrator read the OpenSLP users guide before 
# enabling this setting. Default 1s false. Uncomment the line below to 
# enable DA operation. 

;net.slp.isDA = true 


# A 32 bit integer giving the number of seconds for the DA heartbeat. 
# Default 1s 3 hours (10800 seconds). This property corresponds to 
3 the nrotocol snecification narameter CONFIG DA RFAT [7]. Tanored 
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6 Save the file and close it. 

7 Ataterminal prompt, enter the following to restart the SLP daemon and reset its configuration: 
rcslpd restart 

8 Enter the following commands to verify that the DA and scopes you configured are recognized. 
slptool findsrvs service: 
The DA server should be listed. 
slptool findscopes 
The scopes should be listed. 

9 If you did this after installing OES 2015 SP1, enter the following to verify that the tree is found: 
slptool findsrvs service:ndap.novell 


Checking the Status of Novell SLP Services 


There are several ways to check the status of Novell SLP services. 


* |f you know the IP addresses of the DAs, check the SYS: \etc\slp.cfqg file on non-DA servers to 
see if the DA IP addresses are listed. 


* |f you know the scope names, check for the proper scope name configuration by using the SET 
SLP SCOPE LIST command. 
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Use the DISPLAY SLP SERVICES command to list all of the services that are registered in all of 
the scopes that the server is configured to use. 


Use iManager to open the scope container object to see all of the registered services. 


If you are registering different services in different scopes, look in the SYS: Netc*Nsl1p.cfg file for 
REGISTER TYPE lines. 


At the DOS prompt on a Windows workstation with Client32 installed, use the SLPINFO /ALL 
command. 
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The SLP configuration file (etc/slp.conf) is self-documented regarding each of the configuration 
parameters. Novell support has also provided the following TIDS: 


* OpenSLP vs. Novell SLP (http://www.novell.com/support/php/ 


search.do?cmd=displayKC&docType=kc&externalld=7004574&sliceld=1&docTypelID=DT_TID_ 
1 1&dialoglID=246569372&stateld=0%200%20246565813) answers questions about the 
differences between the two SLP solutions. 


eDir not registering bindery or NDAP services with OpenSLP (http://www.novell.com/support/ 
php/ 

search.do?cmd=displayK C&docType=kc&externalld=7001449&sliceld=1&docTypelD=DT_TID_ 
1 1&dialoglD-246569372&stateld—-0962009620246565813) answers questions about how the 
SLP solutions register ndap and bindery services. 


NetWare SLP fails to populate service registrations to an openSLP DA on OES (http:// 
www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=7009783&sliceld=1&docTypelID=DT_TID_ 
1 1&dialogID=281740290&stateld=0%200%20281736877) explains how to solve the 
communication problem. 


OpenSLP Documentation on the Web (http://www.openslp.org/documentation.html)provides 
complete documentation of the OpenSLP services that OES leverages. 
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13.1.1 


Storage and File Systems 


Hosting shared data storage is one of the primary functions of network servers. Whether data 
volumes are directly attached to the server in RAID configurations or externally accessible in Storage 
Area Network (SAN) or Network Attached Storage (NAS) configurations, users need to be able to 
access their data on a continual basis. 


Use this section to understand the file storage solutions available in Open Enterprise Server 2015 or 
later and then to plan a storage solution that meets your file system management needs. 


The "storage and file systems (http://www.novell.com/documentation/oes2015/index.htmlZcat stor- 
file-systems-databases)” links in the OES 2015 SP1 online documentation provides overview, 
planning, implementation, and configuration links. 


This section provides the following information about the process of planning and implementing 
storage services in OES: 


¢ Section 13.1, "Overview of OES 2015 SP1 Storage,” on page 125 
¢ Section 13.2, "Planning OES File Storage," on page 131 
¢ Section 13.3, “Coexistence and Migration of Storage Services,” on page 137 
¢ Section 13.4, “Configuring and Maintaining Storage,” on page 140 
Other storage-related topics in this guide are: 
¢ Chapter 16, "Access Control and Authentication," on page 167 
¢ Section 16.2, "Authentication Services," on page 179 


* Appendix 17, "Backup Services," on page 183 
¢ Chapter 18, "File Services,” on page 185 


Overview of OES 2015 SP1 Storage 


This section presents the following overview information for the file systems included in OES: 


¢ Section 13.1.1, “Databases,” on page 125 

¢ Section 13.1.2, “iSCSI,” on page 126 

¢ Section 13.1.3, “File System Support in OES,” on page 126 

¢ Section 13.1.4, "Storage Basics by Platform,” on page 128 

¢ Section 13.1.5, “Storage Options,” on page 129 

¢ Section 13.1.6, “NetWare Core Protocol Support (Novell Client Support) on Linux," on page 130 


Databases 


See the MySQL documentation (http://dev.mysql.com/doc) on the Web. 
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ISCSI 


See the topics in “iSCSI for Linux (http://www.suse.com/documentation/sles11/stor admin/data/ 
cha inst system iscsi.html)" in the SLES online documentation. 


File System Support in OES 


As shown in Figure 13-1, both OES and NetWare support Novell Storage Services as well as their 
traditional file systems. 


Figure 13-1 File System Choices on OES and NetWare Servers 
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OES NetWare 


-> a = Sp 
= —" E — 
Linux Traditional Novell Storage Services NetWare Traditional Novell Storage Services 
(NSS) (NSS) 
- Ext2 
- Ext3 
- Reiser FS 
- XFS 


- BtrFS (requires the btrfsprogs package) 
Table 13-1 summarizes OES file system types and provides links to more information. 


Table 13-1 File Systems Available on OES and NetWare Servers 


File System Type OES NetWare Summary Link for More Information 
Linux POSIX File Y N SLES 11 SP4 includes a number For an overview of the 
Systems of different file systems, the most supported file systems in 
common of which are Ext3, OES 2015 SP1, see "File 
Reiser, XFS, and Btrfs (requires Systems Overview" in the 
the btrfsprogs package). OES 2015 SP1: File 
. Systems Management 
OES 2015 SP1 services are Guide. 
supported on Ext3, Reiser, XFS, 
and Btrfs. For an overview of Linux 


POSIX file systems, see 
Overview of File Systems in 
Linux in the SLES 11 SP4: 
Storage Administration 


Guide. 
NetWare Traditional N Y This is a legacy file system on For more information, see 
File System NetWare servers that supports the NW6.5 SP8: Traditional 
the Novell file service trustee File System Administration 
access control model. Guide. 
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File System Type OES 


Novell Storage Y 
Services (NSS) 


NetWare 


Y 


Summary 


NSS lets you manage your 
shared file storage for any size 
organization. 


On Netware, NSS features 
include visibility, a trustee access 
control model, multiple 
simultaneous name space 
support, native Unicode, user 
and directory quotas, rich file 
attributes, multiple data stream 
support, event file lists, and a file 
salvage subsystem. 


Most of these features are also 
supported on NSS on Linux. 


In addition, starting in OES 2015 
SP1, NSS supports two pool 
types: NSS32, the traditional 
NSS type that supports up to 8 
Terabytes of data, and NSS64, 
the new NSS type that supports 
up to 8 Exabytes. 


For a feature comparison, see 
"Comparison of NSS on NetWare 
and NSS on Linux” in the OES 
2015 SP1: NSS File System 
Administration Guide for Linux. 


Novell Storage Services (NSS) 


The following sections summarize key points regarding NSS: 


* "Understanding NSS Nomenclature" on page 127 


+ "Comparing NSS with Other File Systems" on page 127 


+ “NSS and Storage Devices" on page 128 


Understanding NSS Nomenclature 


Link for More Information 


For an overview of NSS, 
see "Overview of NSS" in 
the OES 2015 SP1: NSS 
File System Administration 
Guide for Linux. 


NSS uses a specific nomenclature to describe key media objects. These terms appear in both the 
NSS documentation and in NSS error messages. 


For more information, see "NSS Nomenclature" in the OES 2015 SP1: NSS File System 


Administration Guide for Linux. 


Comparing NSS with Other File Systems 


Because OES 2015 SP1 supports a variety of file systems, you might want to compare their features 
and benefits as outlined in the following sections of the OES 2015 SP1: NSS File System 


Administration Guide for Linux: 


* NSS Linux vs. NSS NetWare: "Comparison of NSS on NetWare and NSS on Linux" 
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* NSS Linux vs. NCP Volumes on Linux POSIX: “Comparison of NSS on Linux and NCP 
Volumes on Linux POSIX File Systems" 


NSS and Storage Devices 


NSS supports both physical devices (such as hard disks) and virtual devices (such as software 
RAIDs and iSCSI devices). 


For more information on the various devices that NSS supports, see "Managing Devices" in the OES 
2015 SP1: NSS File System Administration Guide for Linux. 


Storage Basics by Platform 


The following sections summarize storage basics for Linux and NetWare. 


¢ "Linux and File Systems" on page 128 

+ “NSS on OES Storage Devices" on page 128 
+ “NetWare Directories" on page 128 

+ “NetWare Storage Devices" on page 128 


Linux and File Systems 


For a high-level overview of the file system on Linux, including the root (/) directory, mount points, 
standard folders, and case sensitivity, see "Understanding Directory Structures in Linux POSIX File 
Systems" in the OES 2015 SP1: File Systems Management Guide. 


NSS on OES Storage Devices 


See "Guidelines for NSS Storage" in the OES 2015 SP1: NSS File System Administration Guide for 
Linux. 


NetWare Directories 


NetWare uses volumes and directories (or folders) to organize data. NetWare file systems support 
directory paths, fake root directories, Directory Map objects, and drive mappings. 


For more information, see "Understanding Directory Structures for the NSS File System" in the OES 
2015 SP1: File Systems Management Guide. 


NetWare Storage Devices 


NetWare lets you use many different kinds of storage devices, including server disks, single storage 
devices, arrays of storage devices, and virtual storage devices. 


To understand how NetWare connects with and uses storage devices, see "Overview of Server Disks 
and Storage Devices for NetWare" in the NW6.5 SP8: Server Disks and Storage Devices. 
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Storage Options 


The following sections summarize OES storage options. 


+ "Dynamic Storage Technology" on page 129 
* "Direct-Attached Storage Options (NSS and Traditional)" on page 129 
* "Advanced Storage Options" on page 129 


Dynamic Storage Technology 


Dynamic Storage Technology for OES lets you present the files and subdirectories on two separate 
NSS volumes as though they were on a single, unified NSS volume called a shadow volume. 


NCP client users and Novell CIFS users automatically see a merged view of the files and 
subdirectories on the shadow volume when they access a share on the primary volume. All the 
actions they take--renaming, deleting, moving, etc.--are synchronized by Dynamic Storage 
Technology across the two volumes. If you use supported native Linux file access protocols, such as 
Novell Samba, SSH, or Novell FTP (PureFTP-d), to access the DST volume, you can enable 
ShadowFS to provide a merged view location for LUM-enabled users of those protocols. Novell CIFS 
and Novell Samba cannot be used on the same server. 


Backup tools can access the volumes directly and separately, instead of via the merged view shown 
to NCP and CIFS users. You can apply one backup policy to the primary volume and a different 
backup policy to the secondary volume. 


You can use Dynamic Storage Technology to substantially reduce storage costs by placing your less 
frequently accessed files on less expensive storage media. 


In addition, Dynamic Storage Technology doesn't suffer the performance penalty that HSM solutions 
do. 


For more information about Dynamic Storage Technology, see the OES 2015 SP1: Dynamic Storage 
Technology Administration Guide. 


Direct-Attached Storage Options (NSS and Traditional) 


As shown in Figure 13-1 on page 126, you can install traditional volumes and Novell Storage System 
(NSS) volumes on both OES platforms. These devices can be installed within the server or attached 
directly to the server through an external SCSI bus. 


For more information, see "Direct Attached Storage Solutions" in the OES 2015 SP1: Storage and 
File Services Overview. 


Advanced Storage Options 


NSS volumes support the following advanced storage solutions, as documented in the OES 2015 
SP1: Storage and File Services Overview. 


* Network Attached Storage Solutions 


A dedicated data server or appliance that provides centralized storage access for users and 
application servers through the existing network infrastructure and by using traditional LAN 

protocols such as Ethernet and TCP/IP. When Gigabit Ethernet is used, access speeds are 
similar to direct attached storage device speeds. 


The disadvantage is that data requests and data compete for network bandwidth. 
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* Storage Area Network Solutions 


A separate, dedicated data network consisting of servers and storage media that are connected 
through high-speed interconnects, such as Fibre Channel. 


* iSCSI SAN 
You can create a SAN using Linux iSCSI. 
¢ Fault-Tolerant and High-Availability Architectures 
Use one or more of the following technologies: 


* Multiple Path I/O: Multipath I/O software resolves multiple paths to a device into a single 
device and manages the traffic flow across the paths transparently for file systems on the 
devices. NSS on Linux does not provide an LVM-based software solution for managing 
multiple paths like the Media Manager multipath solution on NetWare. Instead, you can use 
Linux multipath I/O tools to configure and manage multiple paths for devices where you 
want to create NSS software RAIDS, pools, and volumes. 


* Software RAIDs: NSS supports software RAIDS to improve storage availability and 
performance by enhancing data fault tolerance and I/O performance. 


For more information, see “Managing NSS Software RAID Devices” in the OES 2015 SP1: 
NSS File System Administration Guide for Linux. 


* Server Clusters: With Novell Cluster Services, you can configure up to 32 servers into a 
high-availability cluster where resources and services are dynamically allocated to any 
server in the cluster and automatically switched to another server if the hosting server fails. 


By manually switching services, IT organizations can maintain and upgrade servers during 
production hours and eliminate scheduled downtime. 


For more information, see the OES 2015 SP1: Novell Cluster Services for Linux 
Administration Guide. To convert a NetWare cluster to an OES cluster, see the OES 2015 
SP1: Novell Cluster Services NetWare to Linux Conversion Guide. 


NetWare Core Protocol Support (Novell Client Support) on 
Linux 


Many organizations rely on Novell Client software and the NetWare Core Protocol (NCP) for highly 
secure file storage services. 


Novell Storage Services (NSS) volumes are NCP volumes by nature, and you can also define Linux 
POSIX volumes as NCP volumes. The main difference in access control between NSS volumes and 
Linux POSIX volumes that are defined as NCP volumes is that NSS extended file and directory 
attributes are not available on Linux POSIX volumes. 


The NCP server for OES lets you attach to Linux POSIX volumes that are defined as NCP volumes 
using Novell Client software. 


NCP support in OES 2015 and later includes support for 64-bit operations and has expanded the 
theoretical limit of NCP volumes to multiple zetabytes. Of course this is limited by server hardware, 
the underlying file system, and other factors. 


For more information, see Section 18.6, “NCP Implementation and Maintenance,” on page 210. 
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13.2.1 


13.2.2 


13.2.3 


Planning OES File Storage 


The following sections can help you plan for storage on your OES network: 


¢ Section 13.2.1, "Directory Structures,” on page 131 


¢ Section 13.2.2, "File Service Support Considerations,” on page 131 


¢ Section 13.2.3, "General Requirements for Data Storage,” on page 131 
¢ Section 13.2.4, “OES 2015 SP1 Storage Planning Considerations," on page 132 


¢ Section 13.2.5, “NSS Planning Considerations," on page 137 


Directory Structures 


To plan the directory structures you need on OES 2015 SP1, see "Understanding Directory Structures 
in Linux POSIX File Systems" in the OES 2015 SP1: File Systems Management Guide. 


File Service Support Considerations 


Figure 13-2 shows which file services can access which volume types. 


Figure 13-2 File Services Supported on Volume Types 
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General Requirements for Data Storage 


NSS-AD Integration 
Samba 


Finding the right storage solution requires you to identify your data storage requirements. You might 
want to compare your list of requirements against those described in “Storage Solutions” in the OES 


2015 SP1: Storage and File Services Overview. 
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13.2.4 OES 2015 SP1 Storage Planning Considerations 


Not all data is the same. Not all workloads are the same. Not all file systems are the same. Matching 
your data and workloads to the available file systems and their capabilities lets you build efficient, 
scalable, and cost-effective solutions. This section discusses issues to consider when planning your 
file systems on OES 2015 SP1 servers, and includes the following topics: 

+ "The Workgroup Environment" on page 132 

* "File System Support" on page 132 

* "File Access Protocol Support" on page 135 

¢ “OES 2015 SP1 Workloads" on page 136 


The Workgroup Environment 


When selecting a file system, it is important to understand the environment in which it operates. For 
OES 2015 SP1, the primary target environment is the workgroup, which requires the following: 


* Ashared file system for Linux, Macintosh, and Windows desktops. Think of this as a NAS 
(network-attached storage) for desktops. 


* Arich, flexible permissions model to maintain security while providing for the management of 
many different users with different permissions throughout the file system. The permissions must 
be granular, allow for delegation of permission management, and ease the administrative burden 
in an environment where change is constant. 


* Arobust enterprise-wide identity management system tied into authentication and file system 
permissions is a must. 


* The capabilities for correcting end user mistakes that are made daily (accidental overwrites, 
deletes, etc.). 


* Integration with collaboration tools. 
* Data encryption on an individual user or group basis for compliance and security. 
* Departmental Web servers and databases. 


* SAN support to provide flexible storage management. 


* 


Backup support for both desktop and server data, with rich tools for monitoring the health of the 
backup system and quickly locating and repairing problems with data protection. 


* 


Regulatory compliance. Regulatory requirements are now pushing new models of protecting and 
storing employee-generated data that is in LAN systems. It is important to apply correct 
regulatory requirements only on those users to which they must be applied, and then to produce 
audits showing compliance. 


* 


Highly available collaboration (e-mail) services, with rich tools to monitor, audit, and trend 
resource usage. 


File System Support 


OES 2015 SP1 offers support for five six systems: Novell Storage Services (NSS), Btrfs, Ext 2, Ext3, 
Reiser, and XFS. Following is an explanation of each file system and the pros and cons of using them 
in the workloads supported by OES 2015 SP1. 

* "Novell Storage Services (NSS)" on page 133 

* "Btrfs" on page 133 

* "Ext2" on page 134 
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* "Ext3" on page 134 
* "Reiser" on page 134 
+ “XFS” on page 135 


Novell Storage Services (NSS) 
¢ Supported only through NSS management tools; not supported through native Linux 
Management tools. 
* Best for shared LAN file serving; excellent scalability in the number of files 
* Journaled 
* Novell Trustee Model and NSS directory and file attributes (such as Rename Inhibit) provide 
access control that is much richer than POSIX and Linux access control lists (ACLs) 


The Novell Storage Services file system is used in NetWare 5.0 and above, is included in the Novell 
Open Enterprise Server. 


The NSS file system is unique in many ways, especially in its ability to manage and support shared 
file services from simultaneous different file access protocols. It is designed to manage access 
control (using a unique model, called the Novell Trustee Model, that scales to hundreds of thousands 
of different users accessing the same storage securely) in enterprise file sharing environments. 


NSS and its predecessor NWFS are the only file systems that can restrict the visibility of the directory 
tree based on the user ID accessing the file system. NSS and NWFS have built-in ACL (access 
control list) rights inheritance. NSS includes mature and robust features tailored for the file-sharing 
environment of the largest enterprises. The file system also scales to millions of files in a single 
directory. NSS also supports multiple data streams and rich metadata; its features are a superset of 
existing file systems on the market for data stream, metadata, name space, and attribute support. 


Beginning with OES 2015 SP1, both eDirectory and Active Directory are supported as identity 
sources, and OES enables the NSS file system to accept Active Directory identities as trustees. 
Active Directory users can authenticate to Active Directory and natively access the NSS resources 
using the CIFS protocol. 


Btrfs 
* Writable snapshots that allow you to easily roll back your system if needed after applying 
updates, or to back up files. 
* Multiple device support that allows you to grow or shrink the file system. 
* Compression to efficiently use storage space. 
* Different RAID levels for metadata and user data. 
* Different checksums for metadata and user data to improve error detection. 
* Integration with Linux Logical Volume Manager (LVM) storage objects. 
* Integration with the YaST Partitioner on SUSE Linux. 
BtrFS creates a default subvolume in its assigned pool of space. It allows you to create additional 


subvolumes that act as individual file systems within the same pool of space. The number of 
subvolumes is limited only by the space allocated to the pool. 


If BtrFS is used for the root (/) file system, you can cover any subdirectory as a subvolume as you 
might normally do. You should also consider covering the following subdirectories in separate 
subvolumes because they contain files that you might prefer not to snapshot for the reasons given: 
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Path Reason to Cover as a Subvolume 


/opt Contains third-party add-on application software packages. 

/SYV Contains http and ftp files. 

/tmp Contains temporary files. 

/var/log Contains log files. 

/var/opt Contains run-time variable data for /opt. 

/var/run Contains run-time variable data. 

/var/spool Contains data that is awaiting processing by a program, user, or administrator, such 


as news, mail, and printer queues. 


/var/tmp Contains temporary files or directories that are preserved between system reboots. 


Ext2 


* Legacy file system 

* Not journaled 

* POSIX access control 
Ext2 does not maintain a journal, so it is generally not desirable to use it for any server that needs 
high availability, with one important exception. If a paravirtualized server is running as a Xen VM 


guest, you should format the /boot partition with Ext2 as explained in Section 9.4, “Xen VMs Need 
Ext2 for the System /Boot Volume,” on page 86. 


Ext3 


* Most popular Linux file system; limited scalability in size and number of files 
* Journaled 
* POSIX extended access control 
The Ext3 file system is a journaled file system that has the widest use in Linux today. It is the default 


file system for SUSE Linux 11 distributions. It is quite robust and quick, although it does not scale well 
to large volumes or a great number of files. 


A scalability feature has been added called H-trees, which significantly improved Ext3's scalability. 
However, it is still not as scalable as some of the other file systems. With H-trees, it scales similarly to 
NTFS. Without H-trees, Ext3 does not handle more than about 5,000 files in a directory. 


Reiser 


* Best performance and scalability when the number of files is great and/or files are small 
* Journaled 


* POSIX extended access control 


Reiser was designed to remove the scalability and performance limitations that exist in Ext2 and Ext3 
file systems. 


Reiser scales and performs extremely well on Linux, outscaling Ext3 with H-trees. In addition, Reiser 
was designed to use disk space very efficiently. 
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XFS 


* Best for extremely large file systems, large files, and lots of files 
* Journaled (an asymmetric parallel cluster file system version is also available) 


* POSIX extended access controls 


The XFS file system is open source and is included in major Linux distributions. It originated from SGI 
(Irix) and was designed specifically for large files and large volume scalability. 


Video and multimedia files are best handled by this file system. Scaling to petabyte volumes, it also 
handles very large amounts of data. It is one of the few file systems on Linux that supports HSM data 
migration. 


File Access Protocol Support 
OES 2015 SP1 offers support for a variety of file access protocols. 


* AFP: The Apple Filing Protocol (AFP) is a network protocol that offers file services for Mac OS X 
and the original Mac OS. 


* CIFS (Novell CIFS and Novell Samba): The Common Internet File Services (CIFS) protocol is 
the protocol for Windows networking and file services. 


Novell CIFS is a ported version of the CIFS file service traditionally available only on NetWare. It 
supports Novell Trustee model access for NSS volumes and Dynamic Storage Technology 
shadow volumes 


Novell Samba is a Novell's customized version of an open source software version of CIFS 
developed after extensive use and analysis of the wire protocol of Microsoft Windows machines. 


Beginning with OES 2015 SP1, both eDirectory and Active Directory users can natively access 
NSS resources using the CIFS protocol. 


* FTP: The File Transfer Protocol (FTP) is one of the most common and widely used simple 
protocols in the Internet. Virtually all plattorms and devices support FTP at some level, but it is a 
very simple protocol, only allowing for uploading and downloading of files. OES provides FTP 
functionality similar to that available on NetWare. For more information, see Section 18.5, 
"Novell FTP (Pure-FTPd) and OES 2015 SP1,” on page 203. 


* HTTP: The Hypertext Transfer Protocol (HTTP) is the dominant protocol on the World Wide Web 
today, and is the one "spoken" by Web browser clients and Web servers. It is like FTP in being 
designed strictly for transfers of HTML (Hypertext Markup Language) and additional markup 
languages that have been invented, such as XML (Extensible Markup Language). 


The NetStorage file service provides secure Internet-based access to files and folders on OES 
and NetWare servers through a browser or Microsoft Web Folders (Microsoft's implementation of 
WebDAV). 


* NCP: The NetWare Core Protocol (NCP) is the client server protocol that was developed by 
Novell for supporting DOS, Windows, OS/2, Macintosh, UNIX (UnixWare), and Linux for shared 
file services. 


The NCP Server included in OES features emulation of the Novell Trustee Model and 
inheritance plus visibility when it runs on traditional POSIX file systems such as Ext3, Reiser, and 
XFS. When it runs on NSS, these capabilities are synchronized with the NSS File system and its 
extended directory and file attributes, such as Rename Inhibit. 
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OES 2015 SP1 Workloads 


Each file system has its strengths and weaknesses depending on the workload the file system 
supports. This section gives some guidelines for picking and building the right file system for a given 
workload. In determining which file system to use for a particular workload, consider your 

environment and the following explanation of each workload to determine which file system best 


meets your workload environment. 


Table 13-2 File System Support per Workload 


Workload Type 


NSS File Btrfs Ext3 File Reiser File XFS File 
System System System System 
AFP (Novell AFP) Supported Not Supported Not Supported Not Supported Not Supported 
CIFS (Novell CIFS) Supported Not Supported Not Supported Not Supported Not Supported 
Cluster Services Recommended Supported Recommended Recommended Recommended 
Collaboration Supported Supported Recommended Supported Supported 
(GroupWise) 
Dynamic Storage Supported Not Supported Not Supported Not Supported Not Supported 
Technology 
File serving — Supported Supported Supported Recommended Recommended 
Application server 
iFolder Recommended Supported Supported Recommended Recommended 
NCP (Novell Client) Recommended Supported Supported Supported Supported 
NetStorage Recommended Supported Recommended Recommended Recommended 
NSS-AD Integration Supported Not Supported Not Supported Not Supported Not Supported 
Printing (iPrint) Recommended Supported Recommended Recommended Recommended 
PureFTP Recommended Supported Recommended Recommended Recommended 


The following sections provide a brief summary of considerations for the workload types listed in 


Table 13-2. 


* “Collaboration (GroupWise)" on page 136 


* “Dynamic Storage Technology” on page 137 


* "File Serving" on page 137 


* "iFolder" on page 137 


* "Novell Cluster Services" on page 137 


* "Printing (iPrint)" on page 137 


Collaboration (GroupWise) 


GroupWise deals with many little files. Because only the application process is accessing the file 
system, the added overhead of the rich ACL and file attributes found in NSS is redundant. The 
necessary characteristics are a file system whose performance remains relatively constant 
regardless of the number of files that are in the volume, and that performs well with small files. 
GroupWise recommends the Ext3 file system. NSS and Reiser are also supported. 


Storage and File Systems 


13.2.5 


13.3 


Dynamic Storage Technology 


Dynamic Storage Technology does not depend on a particular file system in principle; however, it is 
currently supported only on NSS volumes. 


File Serving 


Generally there are two types of NAS use cases: Serving files to application servers in a tiered 
service oriented architecture (SOA), and serving files to end user desktops and workstations. The 
former has minimal access control requirements. The latter has quite heavy access control 
requirements. 


Typically for serving files to application servers (traditional NAS), you would choose a file system that 
is scalable and fast. Reiser and XFS would be good choices in this environment. For file serving to 
end user workstations, the access control and security management capabilities of the NSS file 
systems with AFP, CIFS, and NCP file access protocols are important. 


The NSS model does better than the other file systems for very large numbers of users. It allows for 
security between users and also allows for very fine granular sharing between given users and 
groups. NSS includes a visibility feature implemented in the file system that prevents unauthorized 
users from even seeing subdirectory structures they don't have rights to access. 


iFolder 


Novell iFolder does not depend on a particular file system. Based on the client workload, the file 
system should be chosen at the server side. Because it mostly serves user data, a file system that 
can scale with a large number of files is the best suited in most deployments, making Reiser and NSS 
the best bets. Novell iFolder maintains its own ACL, so having an NSS file system that supports a rich 
ACL might be redundant. 


Novell Cluster Services 


Novell Cluster Services does not depend on a particular file system. For shared storage, the file 
systems software must be available from node to node. For example, if you are using NSS on one 
node, you need to use NSS on the failover node as well. 


Printing (iPrint) 
iPrint is file system agnostic. There is no noticeable difference in performance or reliability on any of 
the file systems. 


NSS Planning Considerations 


To plan for NSS volumes—including prerequisites and security considerations—see "Planning NSS 
Storage Solutions " in the OES 2015 SP1: NSS File System Administration Guide for Linux. 


Coexistence and Migration of Storage Services 


The following sections summarize the coexistence and migration issues related to storage services. 


¢ Section 13.3.1, “Databases,” on page 138 
¢ Section 13.3.2, “NetWare 6.5 SP8,” on page 138 
¢ Section 13.3.3, “OES 2015 SP1 File System Options," on page 139 
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Databases 


The SUSE Linux Enterprise Server 11 (SLES 11) SPA platform on which OES 2015 SP1 services are 
installed, includes two open source databases: 


* "MySQL" on page 138 
* "PostgreSQL" on page 138 


NOTE: Full Novell support of these databases requires a product-specific Novell support contract. 
Documentation and support are available through open source communities as outlined below. 


MySQL 


The SLES 11 platform includes the open source MySQL database server and client. When combined 
with a Web application and a Web server, MySQL is a very reliable and scalable database for use in 
hosting e-commerce and business-to-business Web applications. See the documentation on the Web 
(http://dev.mysql.com/doc/). 


For overview of MySQL and for information about configuring it with Novell Cluster Services, see 
“Configuring MySQL with Novell Cluster Services” in the OES 2015 SP1: Web Services and 
Applications Guide. 


PostgreSQL 


The more powerful PostgreSQL database server also comes with SLES 11. See the PostgreSQL 
documentation on the Web (http://www.postgresql.org/docs/8.3/interactive/index.html). 


NetWare 6.5 SP8 


NetWare 6.5 SP8 supports both the NetWare Traditional file system and Novell Storage Services 
(NSS). 


+ “NetWare Traditional File System" on page 138 
+ “NSS Volumes" on page 138 


NetWare Traditional File System 


Although NetWare 6.5 SP8 supports Traditional volumes, you must upgrade them to NSS before 
upgrading from NetWare to OES. 


NSS Volumes 


To support data migration, NSS volumes are cross-compatible between NetWare and OES servers. 
During a cluster conversion from NetWare 6.5 SP8 to OES, clustered NSS pools that were originally 
created on a NetWare server can fail over between kernels, allowing for full data and file system 
feature preservation when migrating data to OES. For information, see the OES 2015 SP1: Novell 
Cluster Services NetWare to Linux Conversion Guide. 


For additional information about coexistence and migration of NSS volumes, as well as access 
control issues for NSS on OES, see “Migrating NSS Devices to OES 2015 SP1” in the OES 2015 
SP1: NSS File System Administration Guide for Linux. 
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13.3.3 


OES 2015 SP1 File System Options 


OES 2015 SP1 provides support for Novell Storage Services (NSS) as well as Linux POSIX file 
systems. 


+ “NSS Volumes" on page 139 
+ "Linux POSIX File Systems" on page 139 


NSS Volumes 


To support migration from NetWare to OES, NSS volumes are cross-compatible between NetWare 
and Linux. 


On OES, you can use NSS volumes only as data volumes. 


You configure NSS pools and volumes in iManager or NSSMU after the server installation completes 
successfully. You can also use the Novell Linux Volume Manager (NLVM) command line interface. 


Starting with NetWare 6.5 SP4 (and OES 1), a new metadata structure provided enhanced support 
for hard links. After you upgrade your operating system to OES, you must upgrade the media format 
in order to use the new metadata structure; some restrictions apply. For more information, see 
"Upgrading the NSS Media Format' in the OES 2015 SP1: NSS File System Administration Guide for 
Linux. 


For additional information about coexistence and migration of NSS volumes, as well as access 
control issues for NSS on Linux, see "Cross-Platform Issues for NSS" in the OES 2015 SP1: NSS File 
System Administration Guide for Linux. 


Beginning with OES 2015 SP1, both eDirectory and Active Directory are supported as identity 
sources, and OES enables the NSS file system to accept eDirectory and Active Directory identities as 
trustees. For more information, see "Upgrading the NSS Media Format" in the OES 2015 SP1: NSS 
File System Administration Guide for Linux. 


Linux POSIX File Systems 


IMPORTANT: Users can access data storage on OES 2015 SP1 servers through a number of 
methods. For more information, see "Overview of File Services" on page 185. 


OES 2015 SP1 includes tools and services that help bridge the gap between traditional Novell file 
services and Linux POSIX file services. 


* "Management Tools" on page 139 
* "NCP Server" on page 140 
¢ "Novell Cluster Services" on page 140 


Management Tools 


Using NSSMU and the Novell Linux Volume Manager (NLVM) command line interface, you can 
create native Linux POSIX volumes and standalone or clustered Linux Logical Volume Manager 2 
(LVM2) volume groups and logical volumes. 
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13.4.1 


13.4.2 


NCP Server 


OES 2015 SP1 includes NCP Server for Linux. After you create native Linux POSIX volumes, you 
can use NCP Server to create NCP shares on them. You can then manage the shares as NCP 
volumes. 


This lets Novell Client users map drives to Linux POSIX file system data, with access controls being 
enforced by NCP. For more information on using NCP Server for Linux in OES, see the OES 2015 
SP1: NCP Server for Linux Administration Guide. 

Novell Cluster Services 


For information about clustering LVM2 volume groups with Novell Cluster Services, see "Configuring 
and Managing Cluster Resources for Shared LVM Volume Groups" in the OES 2015 SP1: Novell 
Cluster Services for Linux Administration Guide. 


Configuring and Maintaining Storage 


* Section 13.4.1, "Managing Directories and Files," on page 140 
* Section 13.4.2, "Managing NSS,” on page 140 
¢ Section 13.4.3, "Optimizing Storage Performance,” on page 142 


Managing Directories and Files 

To learn about managing directories and files on an OES 2015 SP1 server, see "Understanding 
Directory Structures in Linux POSIX File Systems" in the OES 2015 SP1: File Systems Management 
Guide and "Understanding Directory Structures for the NSS File System" in the OES 2015 SP1: File 
Systems Management Guide. 


Managing NSS 


Use the links in Table 13-3 to find information on the many management tasks associated with NSS 
volumes. 


Table 13-3 NSS Management 


CategorylFeature Description Link 
Compression Conserve disk space and increase the "Managing Compression on NSS 
amount of data a volume can store. Volumes" in the OES 2015 SP1: NSS 
File System Administration Guide for 
Linux 
Console Commands Manage NSS volumes in an OES terminal “NSS Commands" and “NSS Utilities” in 
console via the NSS Console (nsscon) the OES 2015 SP1: NSS File System 
utility. Administration Guide for Linux 


You can also issue Novell Linux Volume 
Manager (NLVM) command line 
commands at the console prompt and in 
scripts. 
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CategorylFeature 


Distributed File 
Services (DFS) 


Description 


Use DFS junctions to transparently 
redirect data requests, split volumes while 
maintaining transparent access, and 
quickly move volume data to another 
volume. 


Link 


OES 2015 SP1: Novell Distributed File 
Services Administration Guide for Linux 


Encryption Create and manage encrypted NSS "Managing Encrypted NSS Volumes" in 
volumes that make data inaccessible to the OES 2015 SP1: NSS File System 
software that circumvents normal access Administration Guide for Linux 
control. 

Hard Links Create multiple names for a single file in “Managing Hard Links" in the OES 2015 
the same or multiple directories in an NSS SP1: NSS File System Administration 
volume. Guide for Linux 

Monitoring Monitor NSS file systems. "Monitoring the Status of the NSS File 


System and Services" in the OES 2015 
SP1: NSS File System Administration 
Guide for Linux 


Multipath Support on 
Linux 


Use Linux Device Mapper Multipath I/O 
tools to manage the dynamic, multiple, 
redundant connection paths between a 
Linux server and its external storage 
devices. 


“Managing Multipath I/O to Devices” in 
the OES 2015 SP1: NSS File System 
Administration Guide for Linux 


Novell Linux Volume 
Manager 


NLVM provides a command line interface 
that lets you manage the NSS file system 
at a terminal console or by using a script. 
It also provides APIs that are used by the 
NSSMU and iManager storage 
management tools. 


OES 2015 SP1: NLVM Reference 


Partitions Manage partitions on NSS volumes. “Managing Partitions” in the OES 2015 
SP1: NSS File System Administration 
Guide for Linux 
Pools Create and manage NSS pools. “Managing NSS Pools” in the OES 2015 
SP1: NSS File System Administration 
Guide for Linux 
Pool Move You can move the contents of a pool from “Move” in the OFS 2015 SP1: NLVM 
one location to another on the same Reference 
system. The destination location can be 
made up of one or multiple devices. If the “Moving a Pool” in the OES 2015 SP1: 
new location is larger than the original NSS File System Administration Guide 
location, the pool is automatically for Linux 
expanded after the move is complete. 
Quotas Set space restrictions for users and “Managing Space Quotas for Volumes, 
directories to control storage usage. Directories, and Users” in the OES 2015 
SP1: NSS File System Administration 
Guide for Linux 
RAID Create and manage software RAIDs. “Managing NSS Software RAID Devices” 


in the OES 2015 SP1: NSS File System 
Administration Guide for Linux 
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Category/Feature 


Salvage subsystem 


Description 


Use the salvage subsystem to make 
deleted files and directories available for 
undelete or purge actions. 


Link 


“Salvaging and Purging Deleted 
Volumes, Directories, and Files” in the 
OES 2015 SP1: NSS File System 
Administration Guide for Linux 


Snapshots Take pool snapshots. “Managing NSS Pool Snapshots” in the 
OES 2015 SP1: NSS File System 
Administration Guide for Linux 

Tools Learn about the various tools available to "Management Tools for NSS” in the OES 


manage NSS volumes, the tool 
capabilities, and how to use them. 


2015 SP1: NSS File System 
Administration Guide for Linux 


Troubleshooting 


Troubleshoot NSS on OES and NetWare 
6.5 SP8. 


“Troubleshooting the NSS File System” 
in the OES 2015 SP1: NSS File System 
Administration Guide for Linux 


File System Trustees 
and Attributes 


Control user access to data by setting 
trustees, trustee rights, and inherited 
rights filters for files. Control file behavior 
by setting file and folder attributes. 


"Configuring File System Trustees, 
Trustee Rights, Inherited Rights Filters, 
and Attributes" in the OES 2015 SP1: 
NSS File System Administration Guide 
for Linux 


Volumes 


Create and manage NSS volumes in NSS 
pools. 


Optimizing Storage Performance 


"Managing NSS Volumes" in the OES 
2015 SP1: NSS File System 
Administration Guide for Linux 


See "Tuning NSS Performance" in the OES 2015 SP1: NSS File System Administration Guide for 


Linux. 
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eDirectory, LDAP, NSS AD, and Domain 
Services for Windows 


This section discusses the following topics: 


* Section 14.1, "Overview of Directory Services,” on page 143 
¢ Section 14.2, “eDirectory,” on page 144 

¢ Section 14.3, "LDAP (eDirectory),” on page 145 

¢ Section 14.4, “NSS AD Support,” on page 146 

¢ Section 14.5, "Why Both NSS AD and DSfW?,” on page 146 


¢ Section 14.6, "Domain Services for Windows,” on page 147 


Overview of Directory Services 


Storing and managing network identities in directory services is a fundamental expectation for 
networking. 


In the simplest terms, NetIQ eDirectory is a tree structure containing a list of objects (or identities) that 
represent network resources, such as the following: 

* Network users 

* Servers 

* Printers 

* Applications 
eDirectory is designed to provide easy, powerful, and flexible management of network resources 


(including eDirectory itself) in ways that no other directory service can match. You can administer 
eDirectory through the same browser-based tools on both OES and NetWare. 
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Figure 14-1 eDirectory Overview 
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NetIQ eDirectory is the central, key component of Novell Open Enterprise Server (OES) and provides 
the following: 


* Centralized identity management 
* The underlying infrastructure for managing your network servers and the services they provide 


* Access security both within the firewall and from the Web 
This section discusses the following tasks: 


¢ Section 14.2.1, “Installing and Managing eDirectory on OES,” on page 144 
¢ Section 14.2.2, "Planning Your eDirectory Tree," on page 145 


¢ Section 14.2.3, “eDirectory Coexistence and Migration," on page 145 


14.2.1 Installing and Managing eDirectory on OES 


The tools you can use to install and manage eDirectory on OES are outlined in the following sections. 


¢ “OES Installation Programs" on page 144 
+ “iManager” on page 145 


OES Installation Programs 


OES requires that eDirectory be installed by using the YaST-based OES install. 
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14.2.2 


14.2.3 


14.3 


IMPORTANT: Cther utilities, such as ndsconfig and ndsmanage, are not supported for installing or 
removing eDirectory on OES servers, unless explicitly called for in OES-specific instructions. 


iManager 


iManager is the OES eDirectory management tool and is used for all eDirectory management and 
most OES component management tasks, including the following: 

* Creating eDirectory objects, including User and Group objects 

* Managing eDirectory objects 

* Configuring and managing OES service component controls in eDirectory 


* Accessing other OES component management tools 


For information on using iManager, see the Net/Q® iManager Administration Guide. 


Planning Your eDirectory Tree 


If you don't have eDirectory installed on your network, it is critical that you and your organization take 
time to plan and design your eDirectory tree prior to installing OES. 


For detailed information on getting started using eDirectory, see "Designing Your NetIQ eDirectory 
Network" in the Net/Q eDirectory 8.8 SP8 Installation Guide. 


To learn what's new in eDirectory 8.8, see the NetIQ eDirectory 8.8 SP8 What's New Guide. 


eDirectory Coexistence and Migration 


Novell Directory Services (NDS) was introduced with NetWare 4.0. The successor to NDS, NetIQ 
eDirectory, is also available for Microsoft Windows, Red Hat, and SUSE versions of Linux, as well as 
various flavors of UNIX (Solaris, AIX, and HP-UX). 


As eDirectory has evolved, backward compatibility issues have arisen. For example, moving from 
NetWare 4.x to 5.x involved not only upgrading NDS, but also moving from IPX to TCP/IP. This 
transition brought significant changes to the core schema and security-related components. Novell 
has consistently provided the migration tools and support required to migrate to new eDirectory 
versions. 


OES 2015 SP1 includes eDirectory 8.8. For those upgrading an existing NetWare 6.5 SP6 server, 
eDirectory 8.7.3 is still available. New NetWare installations require eDirectory version 8.8. 


For complete coexistence and migration information and instructions, see "Migrating to eDirectory 8.8 
SP8” in the Net/Q eDirectory 8.8 SP8 Installation Guide. 


LDAP (eDirectory) 


This section contains information about LDAP support in OES. 


¢ Section 14.3.1, “Overview of eDirectory LDAP Services,” on page 146 

¢ Section 14.3.2, "Planning eDirectory LDAP Services," on page 146 

¢ Section 14.3.3, “Migration of eDirectory LDAP Services," on page 146 

¢ Section 14.3.4, “eDirectory LDAP Implementation Suggestions," on page 146 
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14.3.1 


14.3.2 


14.3.3 


14.3.4 


14.4 


14.5 


Overview of eDirectory LDAP Services 


Lightweight Directory Access Protocol (LDAP) Services for NetIQ eDirectory is a server application 
that lets LDAP clients access information stored in eDirectory. 


Most OES services leverage the LDAP server for eDirectory for authentication, as illustrated in the 
service overviews in this guide. 


Planning eDirectory LDAP Services 


LDAP for eDirectory provides LDAP authentication for the objects stored in eDirectory. As you plan 
your eDirectory tree, be sure you understand the information in "Understanding LDAP Services for 
NetIQ eDirectory” in the NetIQ eDirectory 8.8 SP8 Administration Guide. 


Migration of eDirectory LDAP Services 


If you have users in an OpenLDAP database and you want to migrate them to eDirectory, you can 
use the Novell Import Conversion Export (ICE) utility. For more information, see “NetIQ eDirectory 
Management Utilities" in the Net/Q eDirectory 8.8 SP8 Administration Guide. 


eDirectory LDAP Implementation Suggestions 


OES service LDAP support requires no additional setup or configuration beyond the OES install. 


For help with setting up and using LDAP for eDirectory for other purposes, you can refer to 
“Configuring LDAP Services for NetIQ eDirectory” in the NetIQ eDirectory 8.8 SP8 Administration 
Guide. 


NSS AD Support 


Beginning with OES 2015 SP1, you can provide native CIFS access to NSS volumes by deploying 
the NSS AD Integration service. 


For more information, see the OES 2015 SP1: NSS AD Administration Guide. 


Why Both NSS AD and DSfW? 


NSS AD Integration and Domain Services for Windows (DSfW) are very different services, from a 
directory standpoint. 


Also, DSfW is broader in scope than NSS AD. 
* NSS AD: Provides AD users with native CIFS access to NSS-based storage. 


Other file services such as AFP and NetStorage are not currently supported and are unaffected. 


* DSfW: Provides eDirectory users with native access to Windows servers and services, including 
NTFS-based storage. 
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14.6 Domain Services for Windows 


Novell Domain Services for Windows (DSfW) allows eDirectory users on Windows workstations to 
access storage on both OES servers and Windows servers through native Windows and Active 
Directory authentication and file service protocols. 


DSfW enables companies with Active Directory and NetIQ eDirectory deployments to achieve better 
coexistence between the two platforms. 


* Users can work in a pure Windows desktop environment and still take advantage of some OES 
back-end services and technology, without the need for a Novell Client™ or even a matching 
local user account on the Windows workstation. 


* Network administrators can use Microsoft Management Console (MMC) to administer users and 
groups within the DSfW domain, including their access rights to Samba-enabled storage on OES 
servers. 


This section discusses the following: 


¢ Section 14.6.1, “Graphical Overview of DSfW,” on page 147 
¢ Section 14.6.2, "Planning Your DSfW Implementation," on page 149 
¢ Section 14.6.3, "Implementing DSfW on Your Network,” on page 150 


146.1 Graphical Overview of DSfW 


* "User Management" on page 148 
¢ "Storage Management” on page 149 
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User Management 


Figure 14-2 DSfW User Management Overview 
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Table 14-1 DSfW User Management 


_——————— 


Authenticated Users 


y 


DSfW 
eDirectory server 


AD server 


Users 


Management Tools 


iManager manages DSfW users like other 
eDirectory users. 


MMC manages both AD users and DSfW users 
as though they were AD users. 


DSfW users must have the Default Domain Password policy 
assigned and a valid Universal Password. 


DSfW users are automatically enabled for Samba and LUM. 
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Storage Management 
Figure 14-3 DSfW Storage Management Overview 
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Table 14-2 DSfW Storage Management 


Management Tools Storage 


Network administrators use native OES and Storage devices on OES servers can be either NSS or 
Windows storage management tools to create traditional Linux volumes. Samba management standards 
and manage storage devices on OES and apply to both volume types. 

Windows servers, respectively. 


Windows management tools can also manage 
share access rights and POSIX file system 
rights on DSfW storage devices after the 
shares are created. They cannot create the 
shares or perform other device management 
tasks. 


Planning Your DSfW Implementation 


For planning information, see the OES 2015 SP1: Domain Services for Windows Administration 
Guide. 
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146.3 Implementing DSfW on Your Network 


This section highlights some of the potential caveats to consider when installing DSfW. For complete 
information, see the OES 2015 SP1: Domain Services for Windows Administration Guide, especially 
the "Troubleshooting DSfW" section. 

+ "Implement Universal Password Before DSfW in a Name-Mapped Scenario" on page 150 

+ “DSfW Must Be Installed at the Root of an eDirectory Partition" on page 150 

* "Hierarchical Placement of Users in the eDirectory Tree" on page 150 

+ “OES 2015 SP1 Service Limitations" on page 150 

+ "Install DSfW on a New OES 2015 SP1 Server When Possible" on page 150 

¢ “DNS Configuration" on page 151 


Implement Universal Password Before DSfW in a Name-Mapped 
Scenario 


If you install DSfW into an existing tree and your users don't currently have a Universal Password 
policy assigned, they won't be able to log in without the Novell Client until the Universal Password 
has been set. 


Therefore, you should consider implementing Universal Password and giving users an opportunity to 
log into the network before installing DSfW. Logging in after a password policy is in place creates a 
Universal Password for users so that their transition to DSfW is seamless. 


DSfW Must Be Installed at the Root of an eDirectory Partition 


You must install DSfW in the root container or an eDirectory partition, either one that currently exists 
or one that you create for DSfW. 


Hierarchical Placement of Users in the eDirectory Tree 
DSfW users must reside in the same eDirectory partition where DSfW is installed, either in the same 


container or in a container below it in the hierarchy. Therefore, DSfW should be installed high enough 
in the eDirectory tree that it encompasses all of the users that you want to enable for DSfW access. 


OES 2015 SP1 Service Limitations 


Only designated OES 2015 SP1 services can be installed on a DSfW server. For more information, 
see "Unsupported Service Combinations" in the OES 2015 SP1: Domain Services for Windows 
Administration Guide. 


Install DSfW on a New OES 2015 SP1 Server When Possible 


Because of the service limitations mentioned in OES 2015 SP1 Service Limitations, Novell strongly 
recommends that you install DSfW on a new server. 
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DNS Configuration 


As you set up DNS, observe the following guidelines: 


* First DSfW Server (FRD): This should point to itself as the primary DNS server, and to the 
network DNS server as the secondary DNS server (if applicable). 


* Subsequent DSfW Servers: These must point to the FRD as their primary DNS server and 
optionally to the network DNS server as their secondary DNS server. 


* DSfW Workstations: These must be able to resolve the FRD of the DSfW forest. For example, 
you might configure workstations to point to the FRD as their primary DNS server and to the 
network DNS server secondarily. Or if the network DNS server is configured to forward requests 
to the DSfW server, then workstations could point to it as their primary DNS server. 


eDirectory, LDAP, NSS AD, and Domain Services for Windows 151 


152 eDirectory, LDAP, NSS AD, and Domain Services for Windows 


15.1 


15.2 


Users and Groups 


Networks exist to serve users and groups of users. Open Enterprise Server 2015 or later provides 
strong user and group management through eDirectory and its associated technologies. 
* Section 15.1, "Creating Users and Groups," on page 153 
¢ Section 15.2, "Linux User Management: Access to Linux for eDirectory Users," on page 153 
¢ Section 15.3, "Identity Management Services," on page 162 
¢ Section 15.4, "Using the Identity Manager 4.5 Bundle Edition," on page 163 


Creating Users and Groups 


All OES services require that you create User objects to represent the users on your system. The 
Linux User Management (LUM) and Samba components on OES also require that you create a LUM- 
enabled Group object that you can assign the users to. 


In addition to these basic objects, it is usually helpful to organize your tree structure by using 
Organizational Unit objects to represent the structure of your organization and to serve as container 
objects to help manage the users, groups, servers, printers, and other organization resources you 
can manage through eDirectory. 


For more information about Samba, see Creating eDirectory Users for Samba in the OES 2015 SP1: 
Novell Samba Administration Guide. 


For detailed information on understanding, creating, and managing the various objects your 
organization might require, see the Net/Q eDirectory 8.8 SP8 Administration Guide. 


Linux User Management: Access to Linux for 
eDirectory Users 


NOTE: OES 2015 SP1 includes a new service named the Novell Identity Translator (NIT) that is 
associated with Linux User Management. 


NIT represents a new approach to the service that LUM provides and works seamlessly with LUM to 
provide access to Novell CIFS in OES 2015 SP1. 


For more information about NIT, see Section 1.18, “Novell Identity Translator (NIT),” on page 19. 


Users and groups on NetWare servers are created in and managed through eDirectory; users and 
groups on Linux servers are usually created locally and managed according to the POSIX (Portable 
Operating System Interface) standard. 


Because Open Enterprise Server provides services running on both Linux and NetWare, Novell has 
developed a technology that lets eDirectory users also function as “local” POSIX users on Linux 
servers. This technology is called Linux User Management or LUM. 
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15.2.1 


The following sections outline the basic principles involved in Novell LUM and cover the following 
topics: 

¢ Section 15.2.1, “Overview,” on page 154 

¢ Section 15.2.2, “LUM Changes,” on page 159 

¢ Section 15.2.3, “Planning,” on page 159 

¢ Section 15.2.4, “LUM Implementation Suggestions,” on page 160 


Overview 


The topics in this section are designed to help you understand when LUM-enabled access is required 
so that your network services are accessible and work as expected. For more information about Linux 
User Management, see "Overview" in the OES 2015 SP1: Linux User Management Administration 
Guide. 

* "A Graphical Preview of Linux User Management" on page 154 

* "Linux Requires POSIX Users" on page 155 

¢ "Linux Users Can Be Local or Remote" on page 155 

* "The root User Is Never LUM-Enabled" on page 156 

+ "About Service Access on OES” on page 156 

+ “OES Services That Require LUM-Enabled Access" on page 156 


+ “OES Services That Do Not Require LUM-Enabled Access But Have Some LUM Requirements" 
on page 158 


¢ “OES Services That Do Not Require LUM-enabled Access" on page 158 
* "LUM-Enabling Does Not Provide Global Access to ALL OES Servers" on page 159 
* "LUM-Enabling Required for Full Administrative Access" on page 159 


A Graphical Preview of Linux User Management 


Figure 15-1 illustrates how Linux User Management controls access to the OES server. 
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Figure 15-1 LUM Provides POSIX Access for eDirectory Users 
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The following table explains the information presented in Figure 15-1. 
Table 15-1 Linux User Management 


Valid POSIX Users Authentication eDirectory Authenticated 


Services 


Some services on OES servers 
must be accessed by POSIX users. 


When the system receives an 
action request, it can authenticate 
both local POSIX users and users 
who have been enabled for Linux 
access. 


Users can potentially access PAM- 
enabled services, Samba shares, 
and Novell Remote Manager as 


. i either local or eDirectory users. 
eDirectory users can function as 


POSIX users if they are enabled for 
Linux access (LUM). 


By default, only the sfcb command 
(required for server management) 
is enabled for eDirectory access. 


Linux Requires POSIX Users 


Linux requires that all users be defined by standard POSIX attributes, such as username, user ID 
(UID), primary group ID (GID), password, and other similar attributes. 


Linux Users Can Be Local or Remote 
Users that access a Linux server can be created in two ways: 


* Locally (on the server): Local users are managed at a command prompt (using commands 
such as useradd) or in YaST. (See the useradd(8) man page and the YaST online help for more 
information.) These local users are stored in the /etc/passwd file. (See the passwd(5) man 
page for more information.) 
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IMPORTANT: As a general rule on OES servers, the only local user account that should exist is 
root. All other user accounts should be created in eDirectory and then be enabled for Linux 
access (LUM). You should never create duplicate local and eDirectory user accounts. 


For more information, see Section 6.2, "Avoiding POSIX and eDirectory Duplications," on 
page 64. 


* Remotely (off the server): Remote users can be managed by other systems, such as LDAP- 
compliant directory services. Remote user access is enabled through the Pluggable 
Authentication Module (PAM) architecture on Linux. 


The Linux POSIX-compliant interfaces can authenticate both kinds of users, independent of where 
they are stored and how they are managed. 


The root User Is Never LUM-Enabled 


The OES user management tools prevent you from creating an eDirectory user named root, thus 
replacing the root user on an OES server. If root were to be a LUM user and eDirectory became 
unavailable for some reason, there would be no root access to the system. 


Even if eDirectory is not available, you can still log into the server through Novell Remote Manager 
and perform other system management tasks as the root user. 


About Service Access on OES 


Novell Linux User Management (LUM) lets you use eDirectory to centrally manage remote users for 
access to one or more OES servers. 


In other words, LUM lets eDirectory users function as local (POSIX) users on an OES server. Access 
is enabled by leveraging the Linux Pluggable Authentication Module (PAM) architecture. PAM makes 
it possible for eDirectory users to authenticate with the OES server through LDAP. 


In OES, the terms LUM-enabling and Linux-enabling are both used to describe the process that adds 
standard Linux (POSIX) attributes and values to eDirectory users and groups, thus enabling them to 
function as POSIX users and groups on the server. 


You can use iManager to enable eDirectory users for Linux. For instructions, see "About Enabling 
eDirectory Users for Linux Access" on page 160. 


OES Services That Require LUM-Enabled Access 


Some services on an OES server require that eDirectory users be LUM-enabled to use them: 


* Novell Samba (CIFS) Shares on the Server: Windows workgroup users who need access to 
Samba shares defined on the server must be LUM-enabled eDirectory users who are configured 
to access the server. This is because Samba requires POSIX identification for access. 


By extension, NetStorage users who need access to Samba (CIFS) Storage Location objects 
that point to the server must also be LUM-enabled eDirectory users with access to the server. 


NOTE: Although Samba users must be enabled for LUM, Samba is not a PAM-enabled service. 
Logging in to an OES server through Samba does not create a home directory on the server. 


* Core Linux Utilities Enabled for LUM: These are the core utilities and other shell commands 
that you can specify during the OES install to be enabled for authentication through eDirectory 
LDAP. In Linux, these are known as PAM-enabled utilities or services. 
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IMPORTANT: Before you accept the default PAM-enabled service settings, be sure you 
understand the security implications explained in Section 21.2.2, "User Restrictions: Some OES 
Limitations," on page 229. 


The core utilities available for PAM-enablement are summarized in Table 15-2. 


Table 15-2 PAM-enabled Services Controlled by LUM 


Command Where Executed Task 


ftp Another host Transfer files to and from the OES server which, in 
this case, is a remote host. 


gdm * Local host Run and manage the X servers using XDMCP. 


* Remote host 


gnomesu-pam Local host Required for GNOME applications that need 
superuser access. 


login * OES server Log in to the OES server, either directly or in an SSH 


. , session with the server. 
* SSH session with OES 


server 
sfcb Local host Required for iPrint, NSS, SMS, Novell Remote 
Manager, and iManager. 
sshd Another host Establish a secure encrypted connection with the 
OES server which, in this case, is a remote host. 
su * OES server Temporarily become another user. 
* SSH session with OES This is most often used to temporarily become the 
Server root user, who is not a LUM user and is, therefore, 


not affected by LUM. 


NOTE: Logging in to the OES server through a PAM-enabled service for the first time causes the 
creation of a home directory in /home on the server. 


* Novell Remote Manager on Linux: You can access Novell Remote Manager as the following: 
* The root user with rights to see everything on the Linux server. 


* Alocal Linux user with access governed by POSIX access rights. (Having local users in 
addition to root is not recommended on OES servers.) 


* ALUM-enabled eDirectory user, such as the Admin user created during the install. 
* Novell Storage Management Services (SMS) on Linux: You can access SMS utilities as 


* The root user, who has rights to see everything on the Linux server, including NSS 
volumes. 


* Alocal Linux user with access governed by POSIX access rights. (Having local users in 
addition to root is not recommended on OES servers.) 


* ALUM-enabled eDirectory user, such as the Admin user created during the install. 
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OES Services That Do Not Require LUM-Enabled Access But Have 
Some LUM Requirements 


Some services do not require eDirectory users to be LUM-enabled for service access: 


* 


NetStorage: NetStorage users don't generally need to be LUM-enabled. However, salvaging 
and purging files through NetStorage on an NSS volume can only be done by users who are 
enabled for Linux. 


IMPORTANT: Files that are uploaded by non-LUM users via NetStorage are owned, from a 
POSIX perspective, by the root user. The assumption is that such users are accessing their 
data on NSS or NCP volumes by using an NCP storage location object. In both cases, the Novell 
Trustee Model applies and POSIX ownership is irrelevant. 


If non-LUM NetStorage users are later enabled for Samba access (which means they are then 
LUM-enabled), and they begin using Samba as a file service, their NetStorage uploaded files are 
not accessible through Samba until you make them the file owners from a POSIX perspective. 
Although the Novell implementation of Samba leverages eDirectory for authentication, Samba 
file and directory access is always controlled by POSIX. The Novell Trustee Model doesn't apply 
to Samba. 


Both Novell trustee assignments and POSIX file ownership are tracked correctly after users are 
LUM-enabled. 


Although NetStorage doesn't require LUM-enabled access, the service itself runs as a POSIX- 
compliant system (proxy) User (initially a local user on the OES server) who functions on behalf 
of the end users that are accessing the service. 


If NetStorage must access NSS volumes, this local system user must be moved to eDirectory 
and LUM-enabled because only eDirectory users can access NSS volumes. The OES 2015 SP1 
installation program configures this correctly by default. 


For more information, see Appendix H, "System User and Group Management in OES 2015 
SP1,” on page 257. 


NSS: eDirectory users that access NSS volumes directly through NCP (the Novell Client) are not 
required to be LUM-enabled. 


However, because Novell Samba accesses NSS through the virtual file system layer that makes 
NSS appear to be a POSIX-compliant file system, Samba users must be LUM-enabled to 
access an NSS volume. 


OES Services That Do Not Require LUM-enabled Access 


The following end user services do not require LUM-enabled access: 


* 


* 


* 


* 


iFolder 3.9.2 

iPrint 

NCP Client to an NCP Volume 
NCP Client to an NSS Volume 
Novell AFP 

Novell CIFS 
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15.2.2 


15.2.3 


LUM-Enabling Does Not Provide Global Access to ALL OES Servers 


As you plan to LUM-enable users for access to the services that require it, keep in mind that each 
OES server being accessed must be associated with a LUM-enabled group that the accessing users 
belong to. 


In other words, it is not sufficient to LUM-enable users for access to a single OES server if they need 
access to multiple servers. An association between the LUM-enabled groups that the users belong to 
and the eDirectory UNIX Workstation object associated with each server must be formed by using 
iManager. This can be accomplished for multiple servers by using the process described in "Enabling 
eDirectory Groups and Users for Linux Access" on page 160. 


For more information on LUM, see the OES 2015 SP1: Linux User Management Administration 
Guide. 


LUM-Enabling Required for Full Administrative Access 


The current LUM architecture requires that administrators, administrator equivalents, partition 
administrators, and RBS-enabled managers be LUM-enabled to have full management capabilities. 


LUM Changes 


In response to customer requests for improved LDAP performance, persistent searching for new 
Linux-enabled users and groups has been disabled in OES 2 SP3 and later. 


For more information, see Section 6.10, "LUM Cache Refresh No Longer Persistent," on page 71 and 
"What's New or Changed in Linux User Management” in the OES 2015 SP1: Linux User 
Management Administration Guide. 


Planning 


The following sections summarize LUM planning considerations. 


¢ “eDirectory Admin User Is Automatically Enabled for Linux Access" on page 159 
+ "Planning Which Users to Enable for Access" on page 159 


+ “Be Aware of System-Created Users and Groups" on page 160 


eDirectory Admin User Is Automatically Enabled for Linux Access 


When you install Linux User Management on an OES server, the Admin User object that installs LUM 
is automatically enabled for eDirectory LDAP authentication to the server. 


Planning Which Users to Enable for Access 


You need to identify the eDirectory users (and groups) who need access to services on OES servers 
that require LUM-enabled users. 


This can be easily determined by doing the following: 


1. Review the information in "DES Services That Require LUM-Enabled Access" on page 156. 
2. Identify the servers that will run the services mentioned. 


3. Note the users and groups that need access and then configure their objects and the target 
servers/services for that access. 
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15.2.4 


Be Aware of System-Created Users and Groups 


You should also be aware of the system-created users and groups that are LUM-enabled when NSS 
is installed. For more information, see Appendix H, "System User and Group Management in OES 
2015 SP1," on page 257. 


LUM Implementation Suggestions 


The following sections summarize LUM implementation considerations. 


+ "About Enabling eDirectory Users for Linux Access" on page 160 
* "UNIX Workstation" and "Linux Workstation" Are the Same Thing" on page 160 


* "Enabling eDirectory Groups and Users for Linux Access" on page 160 


About Enabling eDirectory Users for Linux Access 


You can enable eDirectory users for Linux User Management by using either iManager 2.7 or the 
nambulkadd command. 


* iManager: You can enable existing eDirectory users for Linux access by using the Linux User 
Management tasks in iManager. 


You can enable multiple users in the same operation as long as they can be assigned to the 
same primary LUM-enabled group. The enabling process also lets you associate the group with 
one or more OES servers or Linux workstations. 


Samba users are also enabled for Linux access as part of the Samba-enabling process. 


* nambulkadd: If you have eDirectory users and groups that need to be enabled for Linux access, 
you can use the nambulkadd command to modify multiple objects simultaneously. For more 
information, see the OES 2015 SP1: Linux User Management Administration Guide. 


“UNIX Workstation” and "Linux Workstation" Are the Same Thing 


When you use iManager to manage OES access, you might notice some inconsistencies in naming. 


When OES servers are created, a "UNIX Workstation - server name" object is created in eDirectory, 
where server name is the DNS name of the OES server. In some places the iManager help refers to 
these server objects as "Linux Workstation" objects. 


Both "UNIX Workstation" and "Linux Workstation" refer to the same eDirectory objects. 


Enabling eDirectory Groups and Users for Linux Access 


IMPORTANT: Users gain server access through their LUM-enabled group assignment rather than 
through a direct assignment to the UNIX Workstation objects themselves. 


You can enable users for access to multiple OES servers by associating the LUM-enabled groups to 
which the users belong with the UNIX Workstation objects you want users to have access to. 


There are four methods for enabling eDirectory groups and users for Linux access: 


* "Using iManager to Enable Groups and any Users Assigned to Them" on page 161 
* "Using iManager to Bulk-Enable Users in a LUM Group" on page 161 
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* "Using iManager to Bulk-Enable Users in a Container" on page 161 


* "Using LUM Utilities at the Command Prompt" on page 162 


Using iManager to Enable Groups and any Users Assigned to Them 


The following steps assume that the eDirectory Group objects already exist and that any User objects 
you want to enable for Linux at the same time also exist and have been assigned to the groups. 


BW N HM 
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Log in to iManager as the eDirectory Admin user or equivalent. 
Click Linux User Management » Enable Groups for Linux. 
Browse to and select one or more Group objects, then click OK. 


If you want all users assigned to the groups to be enabled for Linux, make sure the Linux-Enable 
All Users in These Groups option is selected. 


Click Next. 

If the groups contain users, click Next to confirm that you want them enabled. 
Browse to and select a UNIX Workstation (OES server) object, then click OK. 
Browse to and select the Unix Config Object for the workstation, then click OK. 
Click Next, click Finish, then click OK. 


Using iManager to Bulk-Enable Users in a LUM Group 


The following steps assume that the eDirectory LUM-enabled Group objects already exist and that 
they have assigned non-LUM-enabled User objects that you want to enable for Linux access. 
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Log in to iManager as the eDirectory Admin user or equivalent. 

Click Linux User Management » Bulk-Enable Users in a LUM Group. 

Browse to and select one or more LUM-enabled Group objects, then click OK. 
Browse to and select the Unix Config Object, then click OK. 

Click Next. 

Click Finish to confirm that you want the listed users enabled for Linux. 

Click OK. 


Using iManager to Bulk-Enable Users in a Container 


The following steps assume that eDirectory non-LUM-enabled User objects exist inside an eDirectory 
container (OU object) and that you want to enable these User objects for Linux access. 
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Log in to iManager as the eDirectory Admin user or equivalent. 
Click Linux User Management » Bulk-Enable Users in a Container. 
Browse to and select the Container (OU) object, then click OK. 
Browse to and select the Unix Config Object, then click OK. 


Browse to and select the LUM-enabled group that you want the users associated with for Linux 
access. 


Click Next. 


7 Observe that all user objects in the container are listed for assignment to the group you have 


selected as the primary group. If you don't want already enabled user objects that are currently 
assigned to a different primary group to have that assignment changed, you must deselect them 
at this point. 
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8 Click Finish to confirm that you want the selected users enabled for Linux (if not already) and 
assigned to the select group. 


9 Click OK. 


Using LUM Utilities at the Command Prompt 


Novell Linux User Management includes utilities for creating new LUM-enabled groups, and for 
enabling existing eDirectory groups for Linux access. 


* The nambulkadd utility lets you use a text editor to create a list of groups you want enabled for 
Linux access. For more information, see “nambulkadd” in the OES 2015 SP1: Linux User 
Management Administration Guide. 


IMPORTANT: Be sure to include a blank line at the end of each text file. Otherwise, the last line 
of the file won't be processed properly. 


* The namgroupadd utility lets you create a new LUM-enabled group or enable an existing 
eDirectory group for Linux access. For more information, see “namgroupadd” in the OES 2015 
SP1: Linux User Management Administration Guide. 


153 Identity Management Services 


Providing network users with a network identity is a fundamental expectation for networking, but it can 
also become confusing when users need to track multiple identities to use network services. When 
you add the traditional POSIX users found on Linux systems to the mix, the picture becomes even 
more complex. 


The identity management services provided by Novell Open Enterprise Server (OES) leverage NetIQ 
eDirectory to simplify and customize identity management to fit your needs: 


* |f you currently store and manage all your users and groups in eDirectory, you can continue to do 
so. 


* |f you use Novell Client software to provide network file and print services, you can provide 
seamless file and print access to OES servers by using the NCP server for Linux and iPrint 
services. For more information, see Section 18.6, “NCP Implementation and Maintenance,” on 
page 210 and Chapter 19, "Print Services," on page 217. 


* |f you want eDirectory users to have access to OES services that require POSIX authentication, 
you can enable the users for Linux access. For more information, see Section 15.2, "Linux User 
Management: Access to Linux for eDirectory Users," on page 153. 


* |f you need to store and manage users in multiple directories, you can greatly strengthen your 
organization's security and dramatically decrease your identity management costs by deploying 
NetIQ Identity Manager. For more information, see Section 15.4, "Using the Identity Manager 4.5 
Bundle Edition," on page 163. 
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15.4 


15.4.1 


15.4.2 


Using the Identity Manager 4.5 Bundle Edition 


NetIQ Identity Manager is a data-sharing solution that leverages the Identity Vault to synchronize, 
transform, and distribute information across applications, databases, and directories. 


The Identity Manager Bundle Edition provides licensed synchronization of information (including 
passwords) held in Active Directory Domains and eDirectory systems. When data from one system 
changes, Identity Manager detects and propagates these changes to other connected systems based 
on the business policies you define. 


This section discusses the following: 


¢ Section 15.4.1, "What Am | Entitled to Use?,” on page 163 
¢ Section 15.4.2, "System Requirements," on page 163 

* Section 15.4.3, "Installation Considerations,” on page 164 

¢ Section 15.4.4, "Getting Started," on page 164 

¢ Section 15.4.5, "Activating the Bundle Edition,” on page 164 


What Am I Entitled to Use? 


The Bundle Edition allows you to use the Identity Manager engine and the following Identity Manager 
drivers: 


* Legacy Identity Manager Driver for eDirectory (eDir2eDir) 


IMPORTANT: The Bi-directional eDirectory driver is not included in the Bundle Edition 
entitlement. 


* Identity Manager Driver for Active Directory 


Other Identity Manager Integration Modules (drivers) are included in the software distribution. You 
can install and use these additional Integration Modules for 90 days, at which time you must purchase 
Identity Manager and the Integration Modules you want to use. 


The User Application and the service drivers (Loopback, Manual Task, and Entitlements) are not 
included as part of the license agreement for the Bundle Edition. In order to use these Identity 
Manager components, you must purchase /dentity Manager. 


System Requirements 


For the latest Identity Manager system requirements, see the Net/Q Identity Manager Integrated 
Installation Guide. 


The Bundle Edition does not include Solaris or AIX support. To run the Identity Manager engine or 
Integration Modules on these platforms, you must purchase Identity Manager. 
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15.43 Installation Considerations 


NetIQ Identity Manager Bundle Edition contains components that can be installed within your 
environment on multiple systems and platforms. Depending on your system configuration, you might 
need to run the installation program several times to install Identity Manager components on the 
appropriate systems. 


In order for the product to be activated, you must install Open Enterprise Server before installing the 
Identity Manager Bundle Edition. For more information on Activation issues, see "Activating the 
Bundle Edition" on page 164. 


NOTE: To install IDM 4.5 Bundle Edition, download the IDM 4.5 Standard Edition and use the IDM 4.5 
Bundle Edition activation keys. 


15.44 Getting Started 


The following sections from the Identity Manager 4.5 documentation will help you plan, install, and 
configure your Identity Manager 4.5 Bundle Edition. 

* Overview 

* Planning 

* Installing Identity Manager 

* Installing Active Directory and eDirectory Drivers 


¢ Password Synchronization across Connected Systems 


See Policy Builder and Driver Customization Guide for information about customizing your Identity 
Manager implementation. 


15.45 Activating the Bundle Edition 


If you choose to purchase additional Identity Manager Integration Modules, you need to install the 
activation credential for those Integration Modules and also the credential for Identity Manager. See 
Activating Identity Manager Products Using a Credential for more information on activating other 
Identity Manager products. 


In order to use the Bundle Edition, you must obtain and install an activation credential. Use the 
following instructions to complete the Bundle Edition activation tasks: 
1 Browse to the Identity Manager Bundle Edition Registration Web site. 
2 Enter your OES activation code, then click Submit. 
3 Do one of the following: 
* Save the Product Activation Credential file. 
Or 


* Open the Product Activation Credential file, then copy the contents of the Product Activation 
Credential to your clipboard. Carefully copy the contents, and make sure that no extra lines 
or spaces are included. You should begin copying from the first dash (-) of the credential (-- 
--BEGIN PRODUCT ACTIVATION CREDENTIAL) through the last dash (-) of the credential 
(END PRODUCT ACTIVATION CREDENTIAL-----). 


4 Open iManager, then choose Identity Manager » Identity Manager Overview and select the 
driver set or browse to a driver set, then click Next. 
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5 On the Identity Manager Overview page, locate the driver set, click the red Activation required 
by link, then click Install Activation. 


6 Select the driver set where you want to activate an Identity Manager component. 
7 Doone of the following: 
* Specify where you saved the Identity Manager Activation Credential, then click Next. 
Or 


* Paste the contents of the Identity Manager Activation Credential into the text area, then click 
Next. 


8 Click Finish. 


Frequently Asked Questions about Activation 


Do I need to Install Identity Manager on a specific server? 


Yes. As a Bundle Edition user, you must install Identity Manager on the server where you installed 
Open Enterprise Server. In order for activation to work properly, you must install Identity Manager on 
OES, and create a driver set on the server. 


l installed the Bundle Edition but it's not activated. Why? 

You must install the Bundle Edition on the server where OES exists. If you install it on a non-OES 
server, the Bundle Edition cannot activate. 

Can I run Identity Manager on a Windows Server? 


Not with the Bundle Edition. However, you can still synchronize data held on a Windows server by 
using the Identity Manager Remote Loader service. The Remote Loader enables synchronization 

between the Identity Manager Engine (on your OES server) and a remote driver (on the Windows 
server.) 


In order to run Identity Manager on a Windows server, you need to purchase /dentity Manager. 


Can I run Identity Manager on a Solaris or AIX Server? 


Not with the Bundle Edition. However, you can still synchronize data held on these platforms by using 
the Identity Manager Remote Loader service. The Remote Loader enables synchronization between 
the Identity Engine and a remote driver (on the Solaris or AIX server.) 


In order to run Identity Manager on Solaris or AIX, you need to purchase /dentity Manager. 


My drivers stopped working. What happened? 


You might have installed the Bundle Edition on a non-OES server. The Bundle Edition must be 
installed on your OES server where OES exists. If Identity Manager is installed on a non-OES 
platform, activation cannot work. After 90 days, your drivers stop running. 


| purchased an additional Integration Module. Why doesn't it work? 


With your OES purchase, you are entitled to use the Bundle Edition products. If you want to add new 
Integration Modules, you also need to purchase /dentity Manager. The Integration Module cannot 
activate until you purchase Identity Manager. 
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If | purchase licenses for NetIQ Identity Manager and an additional Integration 
Module, must I re-install? 


No, you just need to install the activation credentials associated with your purchase. 


How do I know what's activated? 


For information about how to view currently activated products, see Viewing Product Activations for 
Identity Manager and for Drivers. 
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16.1 


16.1.1 


Access Control and Authentication 


Access Control and Authentication are the keys to: 


* Providing services for users. 


* Ensuring that the network is secure. 
This section discusses the following: 


¢ Section 16.1, “Controlling Access to Services," on page 167 
¢ Section 16.2, "Authentication Services," on page 179 


Controlling Access to Services 


IMPORTANT: Beginning with OES 2015 SP1 and NSS-AD integration support, Novell CIFS now 
supports Kerberos authentication for Active Directory users accessing NSS volumes. For more 
information, see the OES 2015 SP1: NSS AD Administration Guide. 


OES supports a number of options for service access, including: 


* Web browsers. 

* File managers and applications on Linux, Macintosh, and Windows workstations. 

* Novell Client software. 

* Personal digital assistants (PDAs) and other electronic devices that are enabled for Web access. 


You control which of these options can be used through the services you offer and the ways you 
configure those services. 


This section can help you understand access control at a high level so that you can plan, implement, 
and control access to services. More detail about the items discussed is contained in individual 
service guides. 


The topics that follow are: 


¢ Section 16.1.1, “Overview of Access Control," on page 167 

* Section 16.1.2, "Planning for Service Access,” on page 174 

¢ Section 16.1.3, “Coexistence and Migration of Access Services," on page 177 
¢ Section 16.1.4, "Access Implementation Suggestions," on page 177 


* Section 16.1.5, "Configuring and Administering Access to Services," on page 177 


Overview of Access Control 


The following sections present overviews of methods for accessing Open Enterprise Server 2015 or 
later services. 


* "Access to OES 2015 SP1 Services" on page 168 
* "Access Control Options in OES" on page 169 
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* "The Traditional Novell Access Control Model" on page 170 
* "NSS Access Control on OES" on page 172 

* "Novell Client (NCP File Services) Access" on page 173 

* "eDirectory User Access to OES Servers" on page 174 

* "Active Directory User Access to OES Servers" on page 174 


Access to OES 2015 SP1 Services 


Figure 16-1 illustrates the access methods supported by OES 2015 SP1 services. NetlQ eDirectory 
provides authentication to each service. 


Figure 16-1 Access Interfaces and the Services They Can Access 
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The interfaces available for each service are largely determined by the protocols supported by the 


service. 


* Browsers and personal digital assistants require support for the HTTP protocol. 


* Each workstation type has file access protocols associated with it. Linux uses NFS as its native 
protocol for file services access, Macintosh workstations communicate using AFP or CIFS, and 


Windows workstations use the CIFS protocol for file services. 


* Novell Client software for both Windows and Linux uses the NetWare Core Protocol (NCP) to 
provide the file services for which Novell is well known. 


Understanding the protocol support for OES services can help you begin to plan your OES 
implementation. For more information, see "Matching Protocols and Services to Check Access 


Requirements" on page 176. 


Access Control Options in OES 


Because OES offers both traditional Novell access control and POSIX access control, you have a 
variety of approaches available to you, including combining the two models to serve various aspects 


of your network services. 


Table 16-1 provides links to documentation that discusses OES access control features. 


Table 16-1 General File System Access Control 


Feature 


Access Control Lists (ACLs) on 
Linux 


To Understand 


How ACLs are supported on the 
most commonly used Linux POSIX 
file systems, and how they let you 
assign file and directory 
permissions to users and groups 
who do not own the files or 
directories. 


See 


"Access Control Lists in Linux" 
(http://www.suse.com/ 
documentation/sles11/ 
book_security/data/cha_acls.html) 
in the SLES 11 SP4: Security Guide 
(http://www.suse.com/ 
documentation/sles11/index.html) 


Aligning NCP and POSIX access 
rights 


How to approximate the Novell 
access control model on POSIX file 
systems. 


“Section 18.4, “Aligning NCP and 
POSIX File Access Rights,” on 
page 200” 


Directory and file attributes 


Directory and file attributes on NSS 
volumes. 


“Understanding Directory and File 
Attributes for NSS Volumes” in the 
OES 2015 SP1: File Systems 
Management Guide 


File system trustee rights 


File system trustee rights on 
NetWare (NSS and traditional 
volumes), including how file system 
trustee rights work. 


“Understanding the OES Trustee 
Model for File System Access” in 
the OES 2015 SP1: File Systems 
Management Guide 


Novell trustee rights and directory 
and file attributes 


How to control who can see which 
files and what they can do with 
them. 
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“Understanding File System Access 
Control Using Trustees” in the OES 
2015 SP1: File Systems 
Management Guide 
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Feature To Understand See 


POSIX file system rights and How to configure file system "Access Control Lists in Linux" 
attributes on Linux attributes on OES 2015 SP1 (http://www.suse.com/ 
servers. documentation/sles11/ 


book_security/data/cha_acls.html) 
inthe SLES 11 SP4: Security Guide 
(http://www.suse.com/ 
documentation/sles11/index.html) 


Security Equivalence in eDirectory The concept of Security “Security Equivalence” in the OES 
Equivalence in eDirectory. 2015 SP1: File Systems 
Management Guide 


The Traditional Novell Access Control Model 


NetWare is known for its rich access control. OES makes these controls available on Linux through 
NSS volume support. In addition, some of the controls are available on Linux POSIX file systems 
through NCP volume creation. NCP volume access controls are not equivalent to NSS because they 
are constrained by Linux POSIX access controls, which offer only a subset of the directory and file 
attributes that NSS offers. 


In the Novell access control model, eDirectory objects, such as users and groups, are assigned File 
System Trustee Rights to directories and files on NSS and NCP volumes. These trustee rights 
determine what the user or group can do with a directory or file, provided that the directory or file 
attributes allow the action. 


This is illustrated in Figure 16-2. 
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Figure 16-2 Directory and File Access under the NetWare Access Control Model 
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Table 16-2 explains the effective access rights illustrated in Figure 16-2. 


Access Control and Authentication 


171 


Table 16-2 Access Rights Explanation 


eDirectory or 
Active 
Directory 
Users and 
Groups 


File System Trustee 
Rights 


eDirectory and File system trustee 
AD users and rights govern access 


groups gain and usage for the 
accesstothe directory or file to which 
file system the rights are granted. 
through their 

respective Trustee rights are 
authentication  0Verridden by directory 
mechanisms. and file attributes. 


For example, even 
though Nancy has the 
Supervisor (all) trustee 
right at the directory 
(and, therefore, to the 
files it contains), she 
cannot delete File2 
because it has the 
Read Only attribute set. 


Of course, because she 
has the Supervisor 
right, Nancy could 
modify the file attributes 
so that File2 could then 
be deleted. 


Directory and File 
Attributes 


Directories and Files 


Each directory and file The possible actions by the users and group 


has attributes 
associated with it. 
These attributes apply 
universally to all 
trustees regardless of 
the trustee rights an 
object might have. 


For example, a file 
that has the Read 
Only attribute is Read 
Only for all users. 


Attributes can be set 
by any trustee that has 
the Modify trustee 
right to the directory or 
file. 


NSS Access Control on OES 


Table 16-3 provides links to documentation that discusses the various NSS-specific access control 


features. 
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shown in this example are as follows: 


* Nancy has the Supervisor trustee right 


at the directory level, meaning that she 
can perform any action not blocked by 
a directory or file attribute. 


The Di (Delete Inhibit) and Ri (Rename 
Inhibit) Attributes on Directory A 
prevent Nancy from deleting or 
renaming the directory unless she 
modifies the attributes first. The same 
principle applies to her ability to modify 
File2. 


Because Joe is a member of the 
Reporters group, he can view file and 
directory names inside DirectoryA and 
also see the directory structure up to 
the root directory. 


Joe also has rights to open and read 
any files in DirectoryA and to execute 
any applications in DirectoryA. 


Because Bert is a member of the 
Reporters group, he can view file and 
directory names inside DirectoryA and 
also see the directory structure up to 
the root directory. 


Bert also has rights to open and read 
File1 and to execute it if it's an 
application. 


And Bert has rights to grant any 
eDirectory user access to File1. 


Because all three users are members 
of the Reporters group, they can grant 
any eDirectory user access to File2. 


Of course, for Nancy this is redundant 
because she has the Supervisor right 
at the directory level. 


Table 16-3 Summary of NSS Access Control Documentation Links 


Feature To Understand See 

Independent Mode vs. NetWare The difference between "Access Control for NSS on Linux" 

Mode Independent Mode access and in the OES 2015 SP1: File Systems 
NetWare Mode access. Management Guide 


This applies only to OES servers, 
not NetWare. 


POSIX directory and file attributes | How NSS file attributes are "Viewing Key NSS Directory and 
on NSS volumes on OES reflected in Linux directory and file File Attributes as Linux POSIX 

f . Men permissions viewable through Permissions" in the OES 2015 SP1: 
This describes what is displayed. — posix, File Systems Management Guide 


POSIX permissions are not actually 
used for access control to NSS 
volumes. 


Novell Client (NCP File Services) Access 


If you have not already determined whether to use the Novell Client on your network, we recommend 
that you consider the following information: 


+ “About the Novell Client" on page 173 
* “Is the Novell Client Right for Your Network?" on page 173 
+ “Differences between Linux and Windows" on page 174 


About the Novell Client 


The Novell Client extends the capabilities of Windows and Linux desktops with access to NetWare 
and OES servers. 


After installing Novell Client software, users can enjoy the full range of Novell services, such as 


* Authentication via NetIQ eDirectory 

* Network browsing and service resolution 
* Secure and reliable file system access 

¢ Support for industry-standard protocols 


The Novell Client supports the traditional Novell protocols (NDAP, NCP, and RSA) and interoperates 
with open protocols (LDAP, CIFS, and NFS). 


Is the Novell Client Right for Your Network? 


Although Novell offers services that don't require Novell Client, (such as NetStorage, Novell iFolder 
3.9.2, and iPrint), many network administrators prefer that their network users access the network 
through the client for the following reasons: 


* They prefer eDirectory authentication to LDAP authentication because they believe it is more 
secure. 

* They prefer the NetWare Core Protocol (NCP) over the Microsoft CIFS protocol because they 
believe that CIFS is more vulnerable to the propagation of viruses on the network. 


Conversely, other network administrators are equally adamant that their users function better without 
the added overhead of running an NCP client on each workstation. 
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We can't determine what is best for you or your network, but we do provide you with viable choices. 


Differences between Linux and Windows 


There are some differences between the Linux and Windows clients. These are documented in 
"Understanding How the Novell Client for Linux Differs from the Novell Client for Windows 2000/XP" 
in the Novell Client 2.0 SP3 for Linux Administration Guide. 


eDirectory User Access to OES Servers 


eDirectory users have access to services on OES servers just like they do on NetWare, with one 
additional consideration—to access some of the services, users must have Linux user credentials, 
such as a user ID (UID) and primary group ID (GID). 


Because eDirectory users don't have Linux user credentials by default, Novell provides the Linux 
User Management (LUM) technology. Users and groups who need access to the affected services, 
must be enabled for eDirectory LDAP authentication to the local server. For more information, see 
"Linux User Management: Access to Linux for eDirectory Users" on page 153. 


Beginning in OES 2015 SP1, Novell also provides the Novell Identity Translator (NIT). For more 
information, see Section 1.18, "Novell Identity Translator (NIT)," on page 19. 


Active Directory User Access to OES Servers 


Active Directory users can be granted access to Novell CIFS shares on NSS volumes. The NSS AD 
integration service must be installed and the Novell Identity Translator must be configured to provide 
user IDs (UIDs) for AD users. For more information, see the OES 2015 SP1: NSS AD Administration 
Guide. 


Planning for Service Access 


After you understand the access options available to your network users, you can decide which will 
work best on your network. 


Planning tips for network services are contained in the following sections: 


* "Planning File Service Access" on page 174 
¢ "Planning Print Service Access” on page 175 


¢ “Matching Protocols and Services to Check Access Requirements" on page 176 


Planning File Service Access 


As you plan which file services to provide, be aware of the file service/volume and feature support 
limitations outlined in the following sections. 


* "Service Access to Volume Type Limitations" on page 174 
* "Feature Support" on page 175 
Service Access to Volume Type Limitations 


Supported combinations are outlined in Table 16-4. 
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Table 16-4 Service Access to Volume Types 


File Service Linux POSIX Volumes NSS Volumes on Linux 

AFP No Yes-Novell AFP 

CIFS Yes-Novell Samba Yes-Novell CIFS, Novell Samba 
NetStorage Yes Yes 

NetWare Core Protocol (NCP) Yes Yes 

NFS Yes Yes-NFSv3 

Novell iFolder 2.1x No No 

Novell iFolder 3.9.2 Yes Yes 


Details about the file systems supported by each file service are explained in the documentation for 
the service. 


Be aware that file services support different sets of access protocols. A summary of the protocols 
available for access to the various OES file services is presented in "Matching Protocols and Services 
to Check Access Requirements" on page 176. 


Feature Support 


Table 16-5 Features Supported on Each Volume Type 


Feature Linux POSIX Volumes NSS Volumes on Linux 

Directory quotas No Yes 

Login scripts Yes (if also defined as an NCP Yes 
volume) 

Mapped drives Yes (if configured as an NCP Yes 
volume) 

Novell directory and file attributes No Yes 

Purge/Salvage No Yes 

Trustee rights Yes (if configured as an NCP Yes 
volume) 

User space quotas No Yes 


Planning Print Service Access 


Novell iPrint has access control features that let you specify the access for each eDirectory User, 
Group, or container object to your printing resources. 


You can also use iPrint to set up print services that don't require authentication. 


NOTE: Access control for printers is supported only on the Windows iPrint Client. 


For more information on access control and iPrint, see "Setting Access Control for Your Print System" 
in the OES 2015 SP1: iPrint Linux Administration Guide 
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Matching Protocols and Services to Check Access Requirements 


Figure 16-3 illustrates the access interfaces available to users in OES and the services that each 
interface can connect to. It also shows the protocols that connect access interfaces with network 
services. 


To use this for planning: 


1. Review the different access interfaces in the left column. 
2. In the middle column, review the protocols each interface supports. 


3. In the right column, view the services available to the interfaces via the protocols. 


Figure 16-3 Access Interfaces and Services, and the Protocols That Connect Them 


Connecting OES Services Available 
Access Interfaces Protocols Through Each Protocol 
Browsers All file services 
a= = 
Lx Mac Win 
iFolder client iFolder only 
p — = 
Lx Mac Win 
File system browsers Linux default protocol 
and applications Novell AFP 
] Q [3] Novell CIFS or Samba 
ess <= iPrint 
Lx Mac Win Internet Explorer to NetStorage, Novell CIFS, Samba 
Novell Client NCP File Services to NCP and NSS volumes 
+> = 
Lx Win 
PDAs NetStorage only 


y 


OES servers 
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16.1.5 


Coexistence and Migration of Access Services 


Because NetWare Core Protocol (NCP) is available in OES, your Novell Client users can attach to 
OES servers as easily as they have been able to attach to NetWare servers. In fact, they probably 
won't notice any changes. 


NCP Server for Linux enables support for login scripts, mapping drives to OES servers, and other 
services commonly associated with Novell Client access. This means that Windows users with the 
Novell Client installed can now be seamlessly transitioned to file services on OES. And with the 
Novell Client for Linux, Windows users can be moved to SUSE Linux Enterprise Desktop with no 
disruption in NCP file services. 


For more information, see the OES 2015 SP1: NCP Server for Linux Administration Guide. 


Access Implementation Suggestions 


After you plan and install OES services, be sure to provide clear access instructions to your network 
users. For a summary of access methods, see Appendix D, "Quick Reference to OES User Services," 
on page 247. 


Configuring and Administering Access to Services 


The following sections discuss administering access to services. 


* "Password Management" on page 177 
* "Linux (POSIX) File System Access Rights" on page 177 
* "NSS File and Directory Trustee Management" on page 178 


Password Management 


Many network administrators let users administer their own passwords. For more information on 
password self management, see "Password Self-Service" in the NetIQ Password Management 
Administration Guide. 


Linux (POSIX) File System Access Rights 


Access control to Linux POSIX file systems is controlled through POSIX file system access rights or 
attributes associated with directories and files. In general, the directories and files can be accessed 
by three POSIX entities: 

* The user who owns the directory or file 

* The group who owns the directory or file 


* All other users defined on the system 


These users and the affected group are each assigned (or not assigned) a combination of three 
attributes for each directory and file: 
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Table 16-6 Linux Access Rights 


Attribute Effect on Directory when Assigned Effect on File when Assigned 

Read Lets the user or group view the directorys Lets the user or group open and read the 
contents. file. 

Write Lets the user or group create or delete files Lets the user or group modify the file. 


and subdirectories in the directory. 


Execute Lets the user or group access the directory Lets the user or group run the file as a 
by using the cd command. program. 


For more information, see "Configuring Trustees and File System Attributes" in the OES 2015 SP1: 
File Systems Management Guide. 


NSS File and Directory Trustee Management 


The OES 2015 SP1: File Systems Management Guide contains a thorough discussion of file and 
directory trustee management in its "Configuring Trustees and File System Attributes" section. 


The following sections present brief information about managing trustees on NSS volumes. 


* "Using NetStorage to Change File and Directory Attributes and Trustees" on page 178 

* "Using iManager 2.7 to Change File and Directory Attributes and Trustee Rights" on page 178 
* "Using the Linux Command Prompt to Change File Attributes" on page 178 

* "Using the Linux Command Prompt to Change Trustee Rights" on page 178 

* "Using rights and NFARM to Manage AD Trustee Assignments on NSS Volumes" on page 179 


Using NetStorage to Change File and Directory Attributes and Trustees 


You can use the NetStorage Web browser interface to change attributes and trustees for directories 
and files on NSS volumes, but you can't change them by using a WebDAV connection to NetStorage. 


Using iManager 2.7 to Change File and Directory Attributes and Trustee Rights 


You can use the iManager 2.7 Files and Folders plug-in to manage directories and files on NCP and 
NSS volumes. For more information, see the plug-in help. 


Using the Linux Command Prompt to Change File Attributes 
Use the attrib command to change file and directory attributes on an NSS volume. 


The attrib command is also documented in "Using the Attrib Utility to Set NSS File System 
Attributes" in the OES 2015 SP1: File Systems Management Guide. 


You can also enter the following command at the command prompt: 


attrib --help 


Using the Linux Command Prompt to Change Trustee Rights 
To grant NSS trustee rights to an NSS volume, enter the following command: 


rights -f /full/directory/path -r rights mask trustee full.object.context 
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where /full/directory/path is the path to the target directory on the NSS volume, rights mask is the list 


of NSS rights, and full.object.context is the object (User or Group) in its full eDirectory context 
including the tree name. 


For example, you might enter the following: 
rights -f /data/groupstuff -r rwfc trustee mygroup.testing.example tree 


For a complete list of command options, enter rights at the command prompt. 


The rights command is also documented in "Using the Rights Utility to Set Trustee Rights for the NSS 


File System" in the OES 2015 SP1: File Systems Management Guide. 


Using rights and NFARM to Manage AD Trustee Assignments on NSS Volumes 


For information, see the OES 2015 SP1: NSS AD Administration Guide. 


Authentication Services 


This section briefly discusses the following topics: 


* Section 16.2.1, "Overview of Authentication Services," on page 179 
* Section 16.2.2, "Planning for Authentication," on page 182 
* Section 16.2.3, "Authentication Coexistence and Migration," on page 182 


* Section 16.2.4, "Configuring and Administering Authentication," on page 182 


Overview of Authentication Services 


This section provides specific overview information for the following key OES components: 


+ "Netldentity Agent" on page 179 
+ “NetlQ Modular Authentication Services (NMAS)” on page 180 
¢ “Password Support in OES” on page 180 


For more authentication topics, see “access, authenticate, log in (http://www.novell.com/ 
documentation/oes11/index.htmlZcat acc-auth-log)" in the OES online documentation. 


Netldentity Agent 


In OES 2015 SP1, the Netldentity Agent works with NetIQ eDirectory authentication to provide 
background eDirectory authentication to NetStorage through a secure identity “wallet” on the 
workstation. 


Netldentity Agent browser authentication is supported only by Windows Internet Explorer. 


The Novell Client provides authentication credentials to Netldentity, but it does not obtain 
authentication credentials from Netldentity because it is not a Web-based application. 


Netldentity Agent requires 


+ XTier (NetStorage) on the OES 2015 SP1 server included in the URL for the Web-based 
applications. 


* The Netldentity agent installed on the workstations. 
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For more information on using the Netldentity agent, see the Net/dentity Administration Guide for 
NetWare 6.5. 


NetlQ Modular Authentication Services (NMAS) 


NetIQ Modular Authentication Services (NMAS) lets you protect information on your network by 
providing various authentication methods to NetlQ eDirectory on NetWare, Windows, and UNIX 
networks. 


These login methods are based on three login factors: 


* Password 
* Physical device or token 


* Biometric authentication 
For example: 


* You can have users log in through a password, a fingerprint scan, a token, a smart card, a 
certificate, a proximity card, etc. 
* You can have users log in through a combination of methods to provide a higher level of security. 


Some login methods require additional hardware and software. You must have all of the necessary 
hardware and software for the methods to be used. 


NMAS software consists of the following: 


* NMAS server components: Installed as part of OES. 


* The NMAS Client: Required on each Windows workstation that will be authenticating using 
NMAS. 


Support for Third-Party Authentication Methods 
Novell Client distributions include a number of NMAS login methods. 


For more information on how to use NMAS, see the Net/Q Modular Authentication Services 
Administration Guide. 


Password Support in OES 


In the past, administrators have needed to manage multiple passwords (simple password, NDS 
passwords, Samba passwords) because of password differences. Administrators have also needed 
to deal with keeping the passwords synchronized. 


In OES you have the choice of retaining your current password maintenance methods or deploying 
Universal Password to simplify password management. For more information, see the Net/Q 
Password Management Administration Guide. 


All Novell products and services are being developed to work with extended character (UTF-8 
encoded) passwords. For a current list of products and services that work with extended characters, 
see Novell TID 3065822 (http://www.novell.com/support/ 
search.do?cmd=displayKC&docType=kc&externalld=3065822&sliceld=1&docTypelD=DT_TID_1 1 
&dialoglD-77556590&stateld-09620096207 7560425). 


The password types supported in eDirectory are summarized in Table 16-7. 
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Table 16-7 eDirectory Password Types 


Password Type Description 


NDS The NDS password is stored in a hash form that is nonreversible in eDirectory. Only the 
NDS system can make use of this password, and it cannot be converted into any other 
form for use by any other system. 


Novell AFP and In OES 2015 SP1, AFP and CIFS users have Universal Password policies assigned by 
Novell CIFS default. More information about password policy planning is available in Appendix J, 
"Coordinating Password Policies Among Multiple File Services," on page 285. 


Samba In OES 2015 SP1, Samba users have a Universal Password policy assigned by default. 


OES 2015 SP1 also supports the Samba hash password if desired. However, you must 
choose to not deploy Universal Password if you want to use the Samba hash password. 
Choosing the Samba password requires that users always remember to synchronize it 
when changing their eDirectory password. 


For more information, see "Samba Passwords" in the OES 2015 SP1: Novell Samba 
Administration Guide. 


Simple The simple password provides a reversible value stored in an attribute on the User object 
in eDirectory. NMAS securely stores a clear-text value of the password so that it can use it 
against any type of authentication algorithm. To ensure that this value is secure, NMAS 
uses either a DES key or a triple DES key (depending on the strength of the Secure 
Domain Key) to encrypt the data in the NMAS Secret and Configuration Store. 


The simple password was originally implemented to allow administrators to import users 
and hashed passwords from other LDAP directories such as Active Directory and iPlanet. 


The limitations of the simple password are that no password policy (minimum length, 
expiration, etc.) is enforced. Also, by default, users do not have rights to change their own 
simple passwords. 


Universal Universal Password (UP) enforces a uniform password policy across multiple 
authentication systems by creating a password that can be used by all protocols and 
authentication methods. 


Universal Password is managed in iManager by the Secure Password Manager (SPM), a 
component of the NMAS module installed on OES servers. All password restrictions and 
policies (expiration, minimum length, etc.) are supported. 


All the existing management tools that run on clients with the UP libraries automatically 
work with the Universal Password. 


Universal Password is not automatically enabled unless you install Novell AFP, Novell 
CIFS, Domain Services for Windows, or Novell Samba on an OES server. (You can 
optionally choose to have the Samba hash password stored separately. This requires, 
however, that users always synchronize the Samba password when changing their 
eDirectory password.) 


The Novell Client supports the Universal Password. It also supports the NDS password 
for older systems in the network. The Novell Client automatically upgrades to use 
Universal Password when UP is deployed. 


For more information, see “Deploying Universal Password" in the NetlQ Password 
Management Administration Guide. 
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16.2.2 Planning for Authentication 


For planning topics, see the "access, authenticate, log in (http://www.novell.com/documentation/ 
oes11/index.htmlzcat acc-auth-log)" in the OES online documentation. 


16.23 Authentication Coexistence and Migration 


n 


For authentication and security coexistence and migration information, see "Chapter 21, "Security, 
on page 225 and Chapter 22, "Certificate Management," on page 233” in this guide. 


16.24 Configuring and Administering Authentication 


For a list of configuration and administration topics, see "access, authenticate, log in (http:// 
www.novell.com/documentation/oes11/index.html#cat_acc-auth-log)” in the OES online 
documentation. 
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17.1 


17.2 


17.2.1 


17.2.2 


The following sections briefly outline the backup services available in Open Enterprise Server 2015 or 


later. 


* Section 17.1, "Services for End Users," on page 183 


¢ Section 17.2, “System-Wide Services," on page 183 


Services for End Users 


OES 2015 SP1 offers a number of services to automatically back up your network users' data files. 


* iFolder 3.9.2: By implementing Novell iFolder 3.9.2, you empower your users to have their local 


files automatically follow them everywhere—online, offline, all the time—across computers. 
Users can share files in multiple iFolders, and share each iFolder with a different group of users. 
Users control who can participate in an iFolder and their access rights to the files in it. Users can 
also participate in iFolders that others share with them. 


Salvage and Purge: By default, all NSS volumes have the Salvage system enabled at the time 
they are created. With Salvage enabled, deleted files are retained on the volume so that users 
can restore (salvage) them. File are eventually purged from the system, either manually, or by 
the system when the Purge Delay setting times out or space is needed on the volume. For more 
information, see "Understanding the NSS Salvage System" in the OES 2015 SP1: NSS File 


System Administration Guide for Linux. 


System-Wide Services 


OES offers both Novell Storage Management Services and services that are available as part of the 


SUSE Linux Enterprise Server distribution. 


¢ Section 17.2.1, "Links to Backup Partners," on page 183 
¢ Section 17.2.2, "Novell Storage Management Services (SMS),” on page 183 
¢ Section 17.2.3, “SLES 11 Backup Services,” on page 184 


Links to Backup Partners 


See the Partners and Communities page on Novell.com (http://www.novell.com/products/ 
openenterpriseserver/partners communities.html). 


Novell Storage Management Services (SMS) 


* "Understanding SMS" on page 184 
* "SMS Coexistence and Migration Issues" on page 184 
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Understanding SMS 


Novell Storage Management Services (SMS) is not a backup application. Rather, it provides a 
standard framework and the necessary interfaces that can be used in developing a complete backup/ 
restore solution. SMS helps back up file systems (such as NSS) on OES servers to removable tape 
media or other media for offsite storage. 


SMS is implemented as two independent components that provide functional abstractions: 


* Storage Management Data Requestor (SMDR) defines the API framework, provides remote 
connectivity, and abstracts the details of communication between servers. 


* Target Service Agent (TSA) provides an implementation of SMS APIs for a particular target. The 
TSA provides transparency by abstracting details of the specific service being backed up. 


For example, various applications use the file system TSA to back up and restore NSS file 
system data and metadata (trustee assignments, file attributes, and name spaces). 


SMS Coexistence and Migration Issues 


In OES 2015 SP1, the SMS API framework is available on SLES 11 so that there is a single 
consistent interface to back up file systems on NetWare, file systems on Linux, and applications such 
as Novell Groupwise, NetIQ eDirectory, and Novell iFolder. The API set has been enhanced to 
include new functionality for OES. 


Most of the SMS coexistence and migration issues are of concern only to backup application 
developers. However, administrators should be aware that SMS-based applications must be used to 
back up and restore NSS file system data on OES servers. Although NSS is exposed as a Virtual File 
System-compliant file system, the Linux interfaces are inadequate to back up NSS file system 
attributes, rich ACLs, trustees, and multiple data streams. 


For additional information, see "Coexistence and Migration Issues" in the OES 2015 SP1: Storage 
Management Services Administration Guide for Linux. 


SLES 11 Backup Services 


Two SLES 11 services might be of interest. 


* DRBD: This lets you to create a mirror of two block devices at two different sites across an IP 
network. When used with HeartBeat 2 (HB2), DRBD supports distributed high-availability Linux 
clusters. For more information, see Distributed Replicated Block Device (DRBD) (http:// 
www.novell.com/documentation/sle ha/book sleha/data/cha ha drbd.html) in the SLES 11 
High Availability Guide (http://www.novell.com/documentation/sle ha/book sleha/data/ 
book sleha.html). 


* rsync: This is useful when large amounts of data need to be backed up regularly or moved to 
another server, such as from a staging server to a Web server in a DMZ. For more information, 
see "Extended Attributes (XAttr) Commands" in the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 
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The file services in Open Enterprise Server 2015 SP1 let you provide Web-based and network-based 
file services to your network users. 


This section contains the following information: 


* 


* 


* 


* 


* 


Section 18.1, "Overview of File Services," on page 185 

Section 18.2, "Planning for File Services," on page 195 

Section 18.3, "Coexistence and Migration of File Services," on page 198 

Section 18.4, "Aligning NCP and POSIX File Access Rights," on page 200 

Section 18.5, "Novell FTP (Pure-FTPd) and OES 2015 SP1," on page 203 

Section 18.6, "NCP Implementation and Maintenance," on page 210 

Section 18.7, "NetStorage Implementation and Maintenance," on page 212 

Section 18.8, "Novell AFP Implementation and Maintenance," on page 214 

Section 18.9, "Novell CIFS Implementation and Maintenance," on page 214 

Section 18.10, "Novell iFolder 3.9.2 Implementation and Maintenance," on page 215 


Section 18.11, "Samba Implementation and Maintenance," on page 216 


18.1 Overview of File Services 


The file service components in OES include the following: 


* 


* 


The file service components in OES are generally compatible. However you cannot run Novell 


FTP Services (page 186): Lets users securely transfer files to and from OES servers. 


NetWare Core Protocol (page 186): Provides NetWare Core Protocol (NCP) access to NCP 


volumes (including NSS volumes) that you define on OES server partitions. 


NetStorage (page 187): Provides network and Web access to various file services through 


common file service protocols, such as CIFS. 


The NetStorage server doesn’t actually store files and folders. Rather, it provides access to other 


file services that support the native TCP/IP protocol. 


Novell AFP (page 190): Provides native Macintosh access to files stored on an NSS volume on 


an OES server. 


Novell CIFS (page 191): Provides native Windows (CIFS and HTTP-WebDAV) access to files 


stored on an NSS volume on an OES server. 


Novell iFolder 3.9.22 (page 192): Provides a Web-based and network-based repository (Novell 


iFolder server) that stores master copies of locally accessible files on the OES server. 


Novell Samba (page 194): Provides Windows (CIFS and HTTP-WebDAV) access to files stored 


on an OES server's file system. 


Samba on the same OES server as Novell AFP, Novell CIFS, or Domain Services for Windows, which 


is not reviewed as a file service, but includes an alternative Samba file service instead of Novell 


Samba. 
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18.1.2 


18.1.3 


Using the File Services Overviews 


Each graphical overview in the following sections introduces one of the OES file service components. 
If visual presentations help you grasp basic concepts, continue with the following overviews. If you 
prefer to skip the overviews, go to Section 18.2, "Planning for File Services," on page 195. 


FTP Services 


OES 2015 SP1 offers a level of integration between eDirectory and Pure-FTP that allows users to 
authenticate to eDirectory for FTP access to the server. You simply select the Novell FTP Server 
pattern in the OES 2015 SP1 installation, then make sure the users needing access are LUM-enabled 
and have access rights to the areas on the server they need to use. You can also migrate an existing 
FTP server configuration from a NetWare server to OES 2015 SP1. 


For migration instructions and a brief FAQ, see "Migrating FTP to OES 2015 SP1" in the OES 2015 
SP1: Migration Tool Administration Guide. 


For documentation on Pure-FTP, visit the Pure-FTP Web site (http://pureftpd.sourceforge.net/ 
documentation.shtml). 


NetWare Core Protocol 


NetWare Core Protocol (NCP) is the technology beneath many of the network services for which 
NetWare is famous. 


In OES, NCP is also available on Linux. The Novell NCP Server for Linux provides the rich file 
services that Novell is known for. Windows and Linux users who run Novell Client software can 
access data, manage files and folders, map drives, etc., using the same methods as they do on 
NetWare servers. 


Figure 18-1 illustrates the basics of NCP file services. For more information on how NCP can help 
you manage access to network resources, see "Access Control and Authentication" on page 167. 
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Figure 18-1 NCP Services for Linux and NetWare 
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The following table explains the information illustrated in Figure 18-1. 


Table 18-1 NCP Access 


Access Methods Authentication NCP Services 

Access is through an NCP client— All file service access is controlled Files are stored on NetWare or NCP 

specifically, the Novell Client. by eDirectory authentication. volumes that the administrator has 
created. 


The same core set of NetWare file 
attributes are available on both Linux 
and NetWare. 


18.14  NetStorage 


* "Common Network File Storage Problems" on page 187 
* "NetStorage" on page 188 


NetStorage makes network files available anywhere, any time. 


Common Network File Storage Problems 


Network file access is often confusing and frustrating to users, as illustrated in Figure 18-2. 
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Figure 18-2 Common Network File Storage Problems 
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The following table explains the information illustrated in Figure 18-2. 


Table 18-2 NetStorage Access Solutions 


Access Methods Authentication Target File Systems Solution: NetStorage 
Browser or PDA accessis Authentication helps Having diverse file Novell NetStorage ties 
critical to those who must protect information storage services only all of these issues 
travel. However, access assets, but having diverse adds to the complexity together with an easy- 
method support varies authentication methods and confusion. to-administer, easy-to- 
widely among file service leads to frustration and use solution. 
providers. lost productivity. 

NetStorage 


NetStorage on OES provides local and Web access to files on many systems without requiring the 
Novell Client (see Figure 18-3). 
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Figure 18-3 How NetStorage Works on OES 
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The following table explains the information illustrated in Figure 18-3. 
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Table 18-3 NetStorage on Linux 


Access Methods Authentication NetStorage Server Target Servers 
Users have read and write File service access is The NetStorage server NetStorage on Linux can 
access to files from controlled by LDAP- receives and connect eDirectory users to 
based authentication processes connection their files and folders stored 
* Windows Explorer: through the eDirectory requests and provides _ in the following locations: 
LDAP server. access to storage on 
Enabled by the HTTP various servers onthe  * Windows workgroup 
protocol with WebDAV Although shown network. shares (CIFS or 
extensions. separately, eDirectory Samba shares) 
« (Broweere:Usersican could be running on the + Linux POSIX volumes 
access files directly by CES server, through an SSH 
connecting to the connection. 


NetStorage server. 


* PDAs: PDA users with 
network connections can 
access their files as well. 


Linux volumes can also be 
made available as NCP 
volumes. 


Management of NSS 
volumes on OES through 
NetStorage requires SSH 
access to the server. See 
"When Is SSH Access 
Required?" on page 93. 


Access is granted through 
login script drive mapping 
(NCP server required) or 
through Storage Location 
Objects. 


18.15 Novell AFP 


The Novell AFP service lets users on Macintosh workstations access and store files on OES servers 
with NSS volumes (see Figure 18-4). 


Figure 18-4 How Novell AFP Works 
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Table 18-4 AFP Access 


Access Points Authentication 


eDirectory users on Macintosh workstations have native All file service access is controlled by LDAP-based 
access to NSS volumes on the OES server. authentication through the eDirectory LDAP server. 


18.16 Novell CIFS 


The Novell CIFS service lets users on Windows workstations access and store files on OES servers 
with NSS volumes without installing any additional software, such as the Novell Client (see Figure 18- 
4). 


Figure 18-5 How Novell CIFS Works for eDirectory Users 
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Table 18-5 CIFS Access for eDirectory Users 


Access Methods Authentication 

eDirectory users on Windows workstations have two native All file service access is controlled by LDAP- 

Windows file access options: based authentication through the eDirectory 
server. 


* CIFS Client Access: Windows Explorer users can access 
and modify files on the OES server just as they would on 
any workgroup server share. 


* Web Folder: Users can create Web Folders in Windows 
Explorer or Internet Explorer. 


Files on the OES server are accessed and maintained 
with the HTTP-WebDAV protocol. 
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Figure 18-6 How Novell CIFS Works for Active Directory Users 
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Table 18-6 CIFS Access for Active Directory Users 
Access Methods Authentication 
Active Directory users gain access to CIFS file services as All CIFS file service access is controlled by 
follows: Kerberos-based authentication and Active 
Directory. 


1. The user presents a Kerberos ticket obtained from Active 
Directory to the Novell CIFS server. 


2. The CIFS server validates the ticket with Active Directory. 


3. After validation, files on the OES server are accessed and 


maintained through the CIFS protocol. 


18.1.7 Novell iFolder 3.9.22 


Novell iFolder 3.9.2 supports multiple iFolders per user, user-controlled sharing, and a centralized 
network server for file storage and secure distribution (see Figure 18-7). 
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Figure 18-7 How Novell iFolder Works 
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The following table explains the information illustrated in Figure 18-7. 


Table 18-7 iFolder Access 


Access Methods Authentication/File Encryption Novell iFolder 3.9.2 
Services 

Linux, Mac, and Windows workstation All file service access is controlled Slave servers can be added 

users who have the Novell iFolder Client by LDAP- based authentication as needed, providing the 

installed can access and modify their files through the eDirectory LDAP ability to dynamically grow 

in one or more workstation folders. server. iFolder services without 

Changes are automatically synchronized disrupting users. 


with the iFolder 3.9.2 Enterprise servers. Although shown separately, 
eDirectory could be installed on the Local and network copies of 


A Web interface lets users access their files OES server. each file are automatically 
from any computer with an active network . synchronized by the Novell 
or Internet connection. Files can be encrypted for transport jFolder Client and Server 


using SSL connections (HTTPS). pieces. 


Additional overview information is available in the Novell iFolder 3.9.2 Administration Guide. 
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Novell Samba on an OES server provides Windows (CIFS and HTTP-WebDAV) access to files stored 
on the OES server (see Figure 18-8). 


Figure 18-8 How Samba on OES Works 
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The following table explains the information illustrated in Figure 18-8. 
Table 18-8 Samba Access 
Access Methods Authentication 
eDirectory users on Windows workstations have two native All file service access is controlled by LDAP- 
Windows file access options (if their eDirectory accounts have based authentication through the eDirectory 
been enabled for LUM and Samba): LDAP server. 


* CIFS Client Access: Windows Explorer users can access 
and modify files on the Samba server just as they would 
on any workgroup server share. 


* Web Folder: Users can create Web Folders in Windows 
Explorer or Internet Explorer. 


Files on the OES server running Samba are accessed and 
maintained with the HTTP-WebDAV protocol. 
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18.2.1 


Samba is an open source initiative. In addition to Linux support, Samba initiatives provide support for 
other platforms such as Apple Computer's operating systems. More information is available on the 
Web (http://www.samba.org). 


Planning for File Services 


Functional overviews of each file service product are included in Section 18.1, "Overview of File 
Services," on page 185. 


¢ Section 18.2.1, “Deciding Which Components Match Your Needs,” on page 195 
¢ Section 18.2.2, "Comparing Your CIFS File Service Options," on page 196 


¢ Section 18.2.3, "Planning Your File Services," on page 197 


Deciding Which Components Match Your Needs 


To decide which file service components to install, you should match service features listed in Table 
18-9 to your network's file service requirements. 


Table 18-9 OES File Services Feature Breakdown 


Service Access Method Features Back-End Storage Features Security Features 

NCP Server Novell Client (NCP client) * Any Linux volumes * eDirectory 

(NetWare Core (including NSS) that are Authentication 

Protocol) defined as NCP volumes 

NetStorage * Any supported * Linux POSIX volumes * Secure LDAP 
browsers Authentication 


* NCP volumes 
* Personal Digital 
* 
Assistant (PDA) NSS volumes 
* * Samba (CIFS) servers 
Remote access 


(browser-based) * Windows (CIFS) servers 


* Web Folders (on either 
an Internet Explorer 
browser or in Windows 
Explorer) 


* Windows Explorer 


Novell AFP * Macintosh Chooser * NSS volumes * Secure LDAP 
Authentication 
Novell CIFS * Any CIFS client * NSS volumes * Secure LDAP 
Authentication 


* Remote access (Web 
Folders in the Internet 
Explorer browser) 


* Windows Explorer 
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Service Access Method Features Back-End Storage Features Security Features 


Novell iFolder 3.9.2 * Linux File Managers * Novell iFolder 3.9.2 * Files can be 
: Enterprise server file encrypted for 
* 
MRCINGSI chooser repository on OES server transport through 
* Offline access with file SSL (HTTPS). 
synchronization + Secure LDAP 
(between local and AS 
: Authentication 
network copies) on 
reconnect 
* Web browsers 
* Windows Explorer 
Except for Web browser 
access, each method above 
requires an installed iFolder 
client. 
Novell Samba * Any CIFS client * Linux POSIX file system * Secure LDAP 
on OES server Authentication 


* Remote access (Web 
Folders in the Internet * NSS volumes 
Explorer browser) 


* Windows Explorer 


18.2.2 Comparing Your CIFS File Service Options 


OES offers three file services that use the CIFS protocol: Novell CIFS, Novell Samba, and Samba in 
Domain Services for Windows (DSfW). 


Table 18-10 Comparing OES CIFS Solutions 


Item Novell CIFS Novell Samba Samba in DSfW 
Authentication A Universal Password A Samba-compatible The Domain Services Password 
Policy that allows the CIFS Password policy is required policy is required for DSfW 
proxy user to retrieve for compatibility with users. The domain is set up as 
passwords is required. Windows workgroup a trusted environment. 
authentication. 
The user who migrates DSfW uses Active Directory 
ACLs for AD users to NSS authentication methods, such 
must have the CIFS as Kerberos, to ensure that only 
universal password policy authorized users can log in to 
applied. This includes the the domain. 
eDirectory Admin user if 
applicable. 


The authentication method 
for NSS AD access is 
Kerberos. 
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Item Novell CIFS Novell Samba Samba in DSfW 


File system NSS is the only file system It is recommended (but not required) that you create Samba 
support supported for this release. shares on NSS data volumes. 


NSS is fully integrated with eDirectory for easier 
management, and using an NSS volume allows you to take 
advantage of the rich data security model in NSS. You can 
use either iManager or the nssmu utility to create an NSS 
volume on an OES server. For instructions on how to set up 
an NSS volume, see "Managing NSS Volumes" in the OES 
2015 SP1: File Systems Management Guide. 


LUM and Samba LUM and Samba Users must be enabled for eDirectory users in the domain 
enablement enablement are not LUM and Samba and (eDirectory partition) are 
required. assigned to a Samba automatically Samba users and 
group. are enabled to access Samba 


shares. See "Creating Users" in 
the OES 2015 SP1: Domain 
Services for Windows 
Administration Guide. 


Domain users are set up with 
the necessary UID and default 
group (DomainUsers) 
membership. 


Every additional eDirectory 
group created within the domain 
is automatically Linux-enabled. 


Username and Beginning with OES 2015, eDirectory users can eDirectory users in the domain 

password both eDirectory and Active access Novell Samba. (eDirectory partition) can log 
Directory users can access into any workstation that has 
Novell CIFS. joined the domain. There is no 


need for a corresponding user 
object on the workstation. 


18.2.3 Planning Your File Services 


1 For the file services you plan to install, compute the total additional RAM required (above the 
basic system requirement). 


* NCP: There are no additional RAM requirements. 

* NetStorage: There are no additional RAM requirements. 
* Novell AFP: There are no additional RAM requirements. 
* Novell CIFS: There are no additional RAM requirements. 


* Novell iFolder 3.9.2: Suggestions for calculating the additional RAM you need are 
contained in "Server Workload Considerations" in the Novell iFolder 3.9.2 Administration 
Guide. 


* Samba: There are no additional RAM requirements. 


2 Record the additional required RAM in your planning notes. 
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3 For the file services you plan to install, compute the total additional disk space required (above 
the basic system requirement). 


* 


NCP: Allocate enough disk space to meet your users’ file storage needs. On Linux, this 
space must exist on partitions you have designated as NCP volumes. 


NetStorage: There are no disk space requirements because NetStorage provides access 
only to other file storage services. 


Novell AFP: Allocate enough disk space for the partition containing the /home directories to 
meet your users' file storage needs. 


Novell CIFS: Allocate enough disk space for the partition containing the /home directories 
to meet your users' file storage needs. 


Novell iFolder 3.9.2: Suggestions for calculating the additional disk space you need are 
contained in "Server Workload Considerations" in the Novell iFolder 3.9.2 Administration 
Guide. 


Samba: Allocate enough disk space for the partition containing the /home directories to 
meet your users' file storage needs. 


4 Record the additional required disk space in your planning notes. 


5 For the file services you plan to install, refer to the information in the sections of the OES 2015 


SP1 


installation guide that are indicated in the following table. 


Note your planning choices on your planning sheet. 


File Service Product Linux Planning References 

NCP "Novell NCP Server / Dynamic Storage Technology" in the OES 2015 
SP1: Installation Guide 

NetStorage "Novell NetStorage" in the OES 2015 SP1: Installation Guide 

Novell AFP "Novell AFP Services" in the OES 2015 SP1: Installation Guide 

Novell CIFS "Novell CIFS for Linux" in the OES 2015 SP1: Installation Guide 

Novell FTP "Novell FTP Services" in the OES 2015 SP1: Installation Guide 

Novell iFolder 3.9.2 "Novell iFolder" in the OES 2015 SP1: Installation Guide 

Samba “Novell Samba" in the OES 2015 SP1: Installation Guide 


Coexistence and Migration of File Services 


Storing shared data on network servers is only half of the picture. The other half is making it possible 


for users 


of Windows, Macintosh, and UNIX/Linux workstations to access the data. 


This section discusses migration of the following services: 


¢ Section 18.3.1, "Novell Client (NCP),” on page 199 
¢ Section 18.3.2, “NetStorage,” on page 199 

¢ Section 18.3.3, "Novell AFP,” on page 199 

¢ Section 18.3.4, "Novell CIFS,” on page 199 

* Section 18.3.5, "Novell iFolder 3.9.2," on page 199 
¢ Section 18.3.6, “Samba,” on page 200 
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18.3.2 


18.3.3 


18.3.4 


18.3.5 


Novell Client (NCP) 


Novell Client for Windows is the long-standing software solution for providing NCP access to 
NetWare data from Windows workstations. The Novell Client extends the capabilities of Windows 
desktops to access the full range of Novell services, such as authentication to eDirectory, network 
browsing and service resolution, and secure file system access. It supports traditional Novell 
protocols such as NCP, RSA, and NDAP, and it interoperates with open protocols such as LDAP. For 
more information on the Novell Client for Windows 7, see the Novell Client 2 SP3 for Windows 
Administration Guide. 


For more information on NCP Server for Linux, see the OES 2015 SP1: NCP Server for Linux 
Administration Guide. 


NetStorage 


NetStorage provides Web access to the files and directories on OES servers from browsers and 
Web-enabled devices such as PDAs. 


Because NetStorage is a service that facilitates access to file services in various locations but doesn't 
actually store files, there are no coexistence or migration issues to consider. 


For more information about NetStorage, see the OES 2015 SP1: NetStorage Administration Guide for 
Linux. 


Novell AFP 


Novell AFP provides native AFP protocol access from Macintosh workstations to data on OES 
servers, offering the same basic AFP connectivity that was previously available only on NetWare. No 
Novell Client software is required. 


For information on migrating AFP services from NetWare to OES 2015 SP1, see “Migrating AFP to 
OES 2015 SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Novell CIFS 


Novell CIFS provides native CIFS protocol access from Windows workstations to data on OES 
servers, offering the same basic CIFS connectivity that was previously available only on NetWare. No 
Novell Client software is required. 


For information on migrating CIFS services from NetWare to OES 2015 SP1, see "Migrating CIFS to 
OES 2015 SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Novell iFolder 3.9.2 


iFolder 3.9.2 supports multiple iFolders per user, user-controlled sharing, and a centralized network 
of servers to provide scalable file storage and secure distribution. Users can share files in multiple 
iFolder folders, and share each iFolder folder with a different group of users. Users control who can 
participate in an iFolder folder and their access rights to the files in it. Users can also participate in 
iFolder folders that others share with them. 


Novell iFolder 3 is only available on OES. 


For information on migrating from iFolder 2 to iFolder 3.9.2, see "Migrating iFolder 2.x" in the OES 
2015 SP1: Migration Tool Administration Guide. 
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18.4.1 


Samba 


OES includes Samba software to provide Microsoft CIFS and HTTP-WebDAV access to files on the 
server. Like Novell CIFS, this is useful to those who don't want to use the Novell Client. 


There is no migration path from Novell CIFS (NFAP) to Samba. 


For more information about Samba in OES 2015 SP1, see the OES 2015 SP1: Novell Samba 
Administration Guide. 


Aligning NCP and POSIX File Access Rights 


NetWare administrators have certain expectations regarding directory and file security. For example, 
they expect that home directories are private and that only the directory owner can see a directory's 
contents. However, because of the differences in the NetWare Core Protocol (NCP) and POSIX file 
security models (see Section 21.2.1, "Comparing the Linux and the Novell Trustee File Security 
Models," on page 227) that is not the case by default on POSIX file systems. 


Fortunately, when you install Linux User Management (LUM) in OES, there is an option to make 
home directories private. This option automatically provides the privacy that NetWare administrators 
are used to seeing. Unfortunately, the option only applies to newly created home directories, so there 
is more to understand and do if aligning access rights is an issue for you. 


Use the information in this section to understand how you can configure POSIX directories to more 
closely align with the NCP model. 


¢ Section 18.4.1, "Managing Access Rights," on page 200 

¢ Section 18.4.2, "Providing a Private Work Directory,” on page 201 
¢ Section 18.4.3, “Providing a Group Work Area," on page 202 

¢ Section 18.4.4, "Providing a Public Work Area," on page 202 

¢ Section 18.4.5, "Setting Up Rights Inheritance," on page 203 


Managing Access Rights 


NCP directories are, by default, private. When you assign a user or a group as a trustee of a directory 
or file, those trustees can automatically navigate to the assigned area and exercise whatever access 
privileges you have assigned at that level and below. You can assign as many trustees with different 
access privileges as you need. 


On the other hand, Linux POSIX directories can be accessed through three sets of permissions 
defined for each file object on a Linux system. These sets include the read (r), write (w), and execute 
(X) permissions for each of three types of users: the file owner, the group, and other users. The Linux 
kernel in OES also supports access control lists (ACLs) to expand this capability. However, ACLs are 
outside the scope of this discussion. For more information on ACLs, see "Access Control Lists in 
Linux" (http://www.suse.com/documentation/sles11/book security/data/cha acls.html) in the SLES 
11 SP4: Security Guide (http:/Awww.suse.com/documentation/sles11/index.html). 


The Linux chown command lets you change the file owner and/or group to a LUM user or a LUM- 
enabled group. For example, chown -R user1 /home/user1 changes the owner of the user1 home 
directory and all its subdirectories and files to user1. For more information, see the chown man page 
on your OES server. 
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The Linux chmod command provides a very simple and fast way of adjusting directory and file access 
privileges for the three user types: owner, group, and other (all users). In its simplest form, the 
command uses three numbers, ranging from 0 through 7, to represent the rights for each of the three 
user types. The first number sets the rights for the owner, the second number sets the rights for the 
group, and the third number sets the rights for all others. Each number represents a single grouping 
of rights, as follows: 


Number Setting Binary Representation 
0 --- 000 
1 x 001 
2 -W- 010 
3 -WX 011 
4 r-- 100 
5 r-x 101 
6 rw- 110 
7 rwx 111 


Those familiar with the binary number system find this method an easy way to remember what each 
number represents. 


For example, the command chmod 777 /home would grant read, write and execute rights (7) to 
owner, group, and other for the /home directory, while chmod 700 /home would grant the three rights 
to only the directory owner, with group and other having no rights. chmod 750 /home would grant rwx 
rights to the owner, r-x rights to the group, and no rights to other users. 


For more information about the chmod command, see the chmod man page on your OES server. 


Providing a Private Work Directory 


To make an NCP directory private, you assign a single user as the trustee and make sure that no 
unexpected users or groups have trustee rights in any of the parent directories. 


To provide a private work area on a Linux POSIX volume: 
1 Make a LUM-enabled user the directory owner. For example, you could use the chown command 
to change the owner (user), 
chown -R user /path/user dir 


where user is the eDirectory user, path is the file path to the work directory, and user dir is the 
work directory name. The -R option applies the command recursively to all subdirectories and 
files. 


2 Grant only the LUM-enabled user read, write, and execute rights (rwx --- --- ) to the directory. For 
example, you could use the chmod command as follows, 


chmod -R 700 /path/user dir 
where path is the file path to the work directory, and user dir is the work directory name. 


3 Check each parent directory in the path up to the root (/) directory, making sure that all users 
(referred to as "other users" in Linux) have read and execute rights (r-x) in each directory as 
shown by the third group of permissions (...... r-x). (Owner and group permissions are 
represented by dots because their settings are irrelevant.) 
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The reason for checking directories is that in the parent directories the directory owners are 
"other" users and they need to be able to see the path down to their own private directories. 


Because r-x is the default for most directories on Linux, you probably won't need to change the 
permissions. 


Providing a Group Work Area 


On an NCP volume, you can provide a group work area by assigning users to a LUM-enabled group 
and then granting the group trustee rights to the directory. As an alternative, if users need different 
levels of access within the work area, you can assign each user as a trustee and grant only the rights 
needed. 


To provide a group work area on a Linux POSIX volume: 


1 Use the chown command to set group ownership for the directory. For example, you could enter 
chown -R :group /path/group dir 


where group is the LUM-enabled group name, path is the file path to the work area, and 
group dir is the group work directory. The -R option applies the action to all subdirectories and 
files in group dir. 


2 Grant the LUM-enabled group read, write, and execute rights (. . . rwx . . .). (Owner and other 
permissions are represented by dots because their settings are irrelevant.) 


For example, you could enter 
chmod -R 770 /path/group dir 


where path is the file path to the work area, and group dir is the group work directory. The 
second 7 grants rwx to the group. (The example assumes that the owner of the directory should 
also retain all rights. Therefore, the first number is also 7.) 


3 Check each parent directory in the path up to the root (/)directory, making sure that the group 
has read and execute rights (r-x) in each directory as shown by the second group of permissions 
(...0-X...). 


Use the chmod command to adjust this where necessary by specifying the number 5 for the 
group permission. For more information, see “Section 18.4.1, “Managing Access Rights,” on 
page 200.” 


Providing a Public Work Area 


On an NCP volume, you can provide a public work area by assigning [Public] as a trustee and then 
granting the required trustee rights to the directory. 


For the work area itself, you would set permissions for the owner, group, and all others to read, write, 
and execute rights (rwx rwx rwx) (chmod 777). 


All others must also have read and execute rights on the system in each parent directory in the path 
all the way to the root of the Linux system. This means that you set permissions for all parent 
directories to rwx --- r-x. 


To provide a public work area on a Linux POSIX volume: 


1 Use the chown command to assign all rights (rwx) to other (all users). For example, you could 
enter 


chmod -R 707 /path/group dir 
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18.5.2 


where path is the file path to the work area, and group dir is the group work directory. The third 7 
grants rwx to the group. (The example assumes that the owner of the directory should also retain 
all rights and that the group setting is irrelevant.) 


2 Check each parent directory in the path up to the root (/)directory, making sure that all users 
(other) have read and execute rights (r-x) in each directory as shown by the third group of 
permissions (...... rwx). (Owner and group permissions are represented by dots because their 
settings are irrelevant.) 


Use the chmod command to adjust this where necessary by specifying the number 5 for the 
other permission. For more information, see "Managing Access Rights" at the beginning of this 
section. 


Setting Up Rights Inheritance 


The final step in aligning POSIX rights to the NCP model is setting the Inherit POSIX Permissions 
volume flag in the NCP configuration file so that all files and subdirectories created in these areas 
inherit the same permissions as their parent directory. For instructions, see "Configuring Inherit 
POSIX Permissions for an NCP Volume" in the OES 2015 SP1: NCP Server for Linux Administration 
Guide. 


Novell FTP (Pure-FTPd) and OES 2015 SP1 


FTP file services on OES 2015 SP1 servers are provided by Pure-FTPd, a free (BSD), secure, 
production-quality and standard-conformant FTP server. The OES implementation includes support 
for FTP gateway functionality as on NetWare and offers a level of integration between eDirectory and 
Pure-FTP that allows users to authenticate to eDirectory for FTP access to the server. 


The OES implementation also includes support for FTP gateway functionality between Active 
Directory (AD) and Pure-FTP that allows users to authenticate to AD for FTP access to the server. 
For more information, see FTP (Pure-FTPd) and OES 2015 SP1 for AD Users in the OES 2015 SP1: 
NSS AD Administration Guide. 


This section discusses the following topics: 


¢ Section 18.5.1, "Planning for Pure-FTPd,” on page 203 

¢ Section 18.5.2, “Installing Pure-FTPd,” on page 203 

¢ Section 18.5.3, “Home Directory Support in Pure-FTPd,” on page 204 

¢ Section 18.5.4, "Configuring Pure-FTPd on an OES 2015 SP1 Server,” on page 205 


¢ Section 18.5.5, “Administering and Managing Pure-FTPd on an OES 2015 SP1 Server,” on 
page 205 


¢ Section 18.5.6, “Cluster Enabling Pure-FTPd in an OES 2015 SP1 Environment,” on page 209 
¢ Section 18.5.7, “Migrating Pure-FTPd From NetWare to Linux,” on page 210 


Planning for Pure-FTPd 


Before installing Pure-FTPd, make sure that users requiring FTP access are LUM-enabled and have 
access rights to the areas on the server they need to use. 


Installing Pure-FTPd 


To install Pure-FTPd, select the Novell FTP pattern in the OES 2015 SP1 installation. 
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Home Directory Support in Pure-FTPd 


The FTP server supports a home directory for users on local and remote NCP servers. The remote 
server can be an OES server. When the home directory is set for the user in eDirectory, the user is 
placed in the home directory on successful login to the Linux server. 


Pure-FTPd supports three levels of home directory, default home directory, a user specific home 
directory on the local system, and a user specific home directory identified by the value set in 
eDirectory. 


POSIX User Home Directory 


The POSIX home directory is the directory that is available by default on POSIX file systems. The 
POSIX home directory is defined at the file system level and cannot be disabled. 


DefaultHomebDirectory and eDirectory home directories can be disabled. If one or both of them are 
enabled, the following is used to establish the precedence: 


* User specific home directory set in eDirectory 
* Default home directory 
* POSIX user home directory 


User Specific Home Directory in eDirectory 


An administrator can set the home directory for eDirectory users as part of the User object in 
eDirectory. On successful login to the FTP server, the user is placed in the home directory set in the 
user object. The User's home directory can exist either on the OES server that is hosting the FTP 
service or on any other OES server in the same tree. 


A new EnableRemoteHomeDirectory option is now available to support this home directory. By 
default, this option is set to NO and the home directory set for the user in eDirectory is ignored. 


To enable eDirectory based home directory support, you must set both 
EnableRemoteHomeDirectory and remote server to YES. FTP will then read the user's home 
directory from eDirectory and mount it locally. 


Default Home Directory 


DefaultHomeDirectory indicates the path to the common home directory for all FTP users. On 
successful login to the Pure-FTPd, users are placed in the default home directory. The default home 
directory can be local or on a locally mounted NSS path or on a remote NCP Server. It can be either 
an NCP volume or an NSS volume and it can be configured by using the DefaultHomeDirectory 
and DefaultHomeDirectoryServer settings. If the home directory is on a remote server, use 
DefaultHomeDirectoryServer, and set it to the IP or DNS name of the remote NCP server. As with 
any NSS volume, the FTP client should have required rights over the NSS volume whether 
DefaultHomeDirectory is on a local or remote server or not. 


The DefaultHomeDirectoryServer option is now available to differentiate whether 
DefaultHomeDirectory is on a local or remote server. By default, this option is set to NO so 
DefaultHomeDirectory points to a local path. 


To set DefaultHomeDirectory to point to a remote NCP server with a DNS entry, you must specify 
the full path to the remote server, including the volume name. For example, DefaultHomeDirectory 
/ftphome. You must also set both DefaultHomeDirectory and remote server to YES. 
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NOTE 


¢ If DefaultHomeDirectory path is a POSIX path (non NCP volume) then it is supported only on 
local FTP server and not on remote server. In that case DefaultHomeDirectory path should be / 
home/commonpath (any POSIX path) and DefaultHomeDirectoryServer should be Null or 
commented. 


Backslash in Input Paths 
Support for backslashes in input path is provided. Using FTP client on Windows, you can use 


backslash as separator in the path. allow backslash in path option is now available to allow back 
slash in the path. By default the option is set to NO. 


Configuring Pure-FTPd on an OES 2015 SP1 Server 


To configure the Pure-FTPd server on OES 2015 SP1, edit the /etc/pure-ftpd/pure-ftpd.conf 
file. 


NOTE: It is very strongly recommended that you read through the entire /etc/pure-ftpd/pure- 
ftpd.conf file and be familiar with the available parameters and settings. 


For complete details, refer the pure-ftpd man page. 


Administering and Managing Pure-FTPd on an OES 2015 
SP1 Server 


* "Starting Pure-FTPd" on page 205 
* "Initializing Multiple Instances" on page 205 
* "Unloading Specific Instances" on page 206 


* "Pure-FTPd Remote Server Navigation" on page 207 


Starting Pure-FTPd 


Start the Pure-FTPd server using the rcpure-ftpd command. 


Initializing Multiple Instances 


Pure-FTPd is loaded by using a configuration file. Multiple instances of Pure-FTPd can be loaded 
using different configuration files. 


By default, an instance of Pure-FTPd using /etc/pure-ftpd/pure-ftpd.conf file is loaded at the 
boot time by init.d script. For loading multiple instances, new configuration files need to be created. 


To load a new instance of Pure-FTPd: 


1 Create a new configuration file for each instance. 


For example: Copy /etc/pure-ftpd/pure-ftpd.conf to a different location. Rename the file 
to pure-ftpdi.conf and move it to /etc/opt/novell/pure-ftpd1.conf. 
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2 Modify the following settings in the configuration file to avoid IP address or port conflicts between 
the instances: 


* PIDFile: Points to the full path of the PID file created by the pure-ftpd instance. PID file is 
used for unloading a particular instance of pure-ftpd. Hence, ensure that the PID File path is 
unique for every instance. 


For example: /var/run/pure-ftp1.pid, /var/run/pure-ftp2.pid. 


* Bind: By default, pure-ftpd binds to all the IP addresses on the system and listens to 
requests over port 21. Modify the settings of the bind such that all the pure-ftpd instances 
bind to different IP addresses or port combinations. 


also, modify the settings in the /etc/pure-ftpd/pure-ftpd.conf to avoid any IP address 
or port conflict from the second instance. 


For example: If a system has two interfaces with two IP addresses 10.1.1.1 and 10.1.1.2, 
then the bind setting for two pure-ftpd instances can be Bind 10.1.1.1,21 and Bind 
10.1.1.2,21. 


3 Load the new instance using /usr/sbin/pure-config.pl «Full path of the config file» 


For example: /usr/sbin/pure-config.pl /etc/opt/novell/pureftpd-confs/pure- 
ftpdi.conf loads an instance using the config file /etc/opt/novell/pureftpd-confs/pure- 
ftpdi.conf. 


Verifying the Load of a New Instance 
Use the following methods to verify that the new instance of pure-ftpd is successfully loaded: 
* The ps -eaf | grep pure-ftpd command lists all the instances of pure-ftpd loaded on the 
system. 
* The PID file as specified using the PIDFile entry in the configuration file has been created. 


* An FTP connection from the client to the server over the IP address being used by the pure-ftpd 
instance can be created. 


Unloading Specific Instances 


A new script, pure-ftp-stop.pl, is added to unload an instance of pure-ftpd and all its child 
processes. The full path of the configuration file used to load the instance of pure-ftpd must be 
passed to the pure-ftp-stop.pl script. 


For example: /usr/sbin/pure-ftpd-stop.pl /etc/opt/novell/pureftpd-confs/pure- 
ftpd1.conf unloads the instance of pure-ftpd that was loaded using /etc/opt/novell/pureftpd- 
confs/pure-ftp1.conf. 


The PID file of the pure-ftpd instance is also used for unloading the pure-ftpd instance. 


Verifying the Unload of a New Instance 


* The PID file specified using the PIDFile entry in the configuration file has been deleted. 
* The number of instances displayed by ps -eaf | grep pure-ftpd is reduced. 
* An FTP connection request to the server errors out. 


File Services 


Pure-FTPd Remote Server Navigation 


After logging in to the eDirectory tree, users can access files and directories on a remote Linux server 
whether or not the server is running Linux FTP Server software. The remote server can be another 


Linux OES server. 


This section describes how to configure and use the Remote Server Navigation feature. 


+ "Configuring Novell FTP” on page 207 
+ "Path Formats" on page 208 

+ "SITE Command" on page 208 

* "Disable-ascii" on page 209 


Workstation running 
FTP client software 


9, user uses FTP to connect to 
the local Linux FTP Server. 


esococon 


~x 


Linux OES/NetWare server 
FTP running NetWare 4.1 or later 
without the FTP service 


: NCP 

UT W . — W 

e "e V Local Linux server e. user can now 
After logging in to : running the | access files on the 


the FTP server, the FTP service : 
user accesses the Linux OES/NetWare 
remote server from Server. 

the command line. 


The NCP protocol lets you transfer files and navigate to and from remote OES servers. 


To navigate to remote servers, use the following command: 


cd //remote server name/volume/directory pathname 


File operations such as get, put, and delete can be used on the remote server, even without 


changing the directory path to that server. 
For example: 


get //remote server name/volume/directory path/filename 


The double slash (//) indicates that the user wants to access a remote server. After the double slash, 


the first entry must be the name of the remote server. 


Configuring Novell FTP 
Configuration file: /etc/pure-ftpd/pure-ftpd.conf 


The configuration parameters for remote server navigation are as follows: 
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Entry Value Function 


remote server yes Enables remote server navigation for the Pure-FTPd server. 
disallow list oes server yes Disables SITE SLIST command for listing OES machines. 
edir Idap port 389 eDirectory LDAP port 


The following configuration parameters needs to be set for remote server navigation: 


Entry Value Reason Why 


ChrootEveryone no Option yes restricts users to login only to his home directory and cannot 
navigate to other directories including remote OES servers. 


AnonymousOnly no Option yes allows only anonymous logins. 


Path Formats 


Table 18-11 Linux FTP Server path formats 


Task Command Format 

Specifying the volume and directory path name //server_name/volume_name/directory_path 
Navigating to different volumes cd //server_name/volume_name 

Switching back to the home directory cd ~ 

Switching to home directory of any user cd ~user_name 

Switching to the root of the server /root 


NOTE: The Linux FTP Server does not support wildcards at the root of the server. 


SITE Command 
The SITE command enables FTP clients to access features specific to the Linux FTP Server. 
The SITE command has the following syntax: 


SITE [SLIST] 


NOTE: The settings done through SITE commands are valid only for the current session. 


This command is unique to the Linux FTP service and are not standard FTP commands. 


Table 18-12 provides the SITE command along with the description: 
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Table 18-12 Linux FTP SITE command 


Command Description 


SLIST Lists all the OES servers within the eDirectory tree. 
Site list command accepts an eDirectory context in 
LDAP format. By default, site slist command lists all 
the NCP Servers in the entire tree. When context is 
passed to the command it lists all the NCP Servers 
within the context. 


NOTE: All the FTP users needs to be LUM-enabled on the FTP server. 


Disable-ascii 


This command is to enable or disable ascii based file transfer. If this is set to YES, all the file transfe 
are done in a binary mode and the client command 'TYPE A' is ignored. 


Cluster Enabling Pure-FTPd in an OES 2015 SP1 
Environment 


You can configure Pure-FTPd server in active/active mode of Novell Cluster Services. 


* "Prerequisites" on page 209 
* "Active/Active Mode" on page 209 


Prerequisites 


* Novell Cluster Services is installed and setup. 


For step-by-step information on setting up Novell Cluster Services, refer to "Installing, 
Configuring, and Repairing Novell Cluster Services" in the “OES 2015 SP1: Novell Cluster 
Services for Linux Administration Guide." 


Active/lActive Mode 


In active/active cluster mode, multiple instances of FTP server runs on a single node cluster. 
Pure-FTPd must be associated with a shared NSS volume and the DefaultHomeDirectory of users 
must be on the shared NSS volume. 

Configuring Active/Active Mode 


1 Install pure-ftpd on all the cluster nodes by selecting Novell FTP in the OES install. Upgrade 
pure-ftpd on all the nodes with the test RPM. 


2 Enable hard links on the shared NSS volumes. For more information on hard links, see "Hard 
Links Commands" in theOES 2015 SP1: NSS File System Administration Guide for Linux. 
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3 Create a unique configuration file for every FTP server to be associated with a shared NSS 
volume. Ensure that: 


* The Bind setting in the configuration file is same as the IP Address of the virtual server 
created for the NSS pool. 


* The PID file must be unique for each FTP instance running on the cluster. 


4 Copy the configuration file to the shared volume to /etc/opt/novell on the shared volume. 
Copying the configuration file to the shared volume, the file is automatically moved across the 
nodes with the volume and is always available to the FTP Server. 


For example: If the shared volume is FTPVol1, the path to copy the configuration file is /media/ 
nss/FTPVol1/etc/opt/novell/pure-ftpd. 


5 Configure all the FTP servers for DefaultHomeDirectory support. As NSS volume is shared, the 
DefaultHomeDirectory in the configuration file must be on the shared volume. 


For example: If FTPVo11 is the shared volume attached to an FTP Server, DefaultHomeDirectory 
in the configuration file is /media/nss/FTPVol1/FTPShare. 


6 Update the load and unload scripts of the cluster resource. 
* Load script: Add the following command to load the FTP server with the shared volume: 
/usr/sbin/pure-config.pl <Full Path to configuration file> 


For example: If the shared volume is FTPVol1 and the Pure-FTP configuration file is /etc/ 
opt/novell/pure-ftpd/ftpvoli.conf on FTPVol1, the pure-ftpd load command in the 
load script is exit on error /usr/sbin/pure-config.pl /media/nss/FTPVoli/etc/ 
opt/novell/pure-ftpd/ftpvol1.conf. 


* Unload script: Add the following command to unload the FTP server: 
/usr/sbin/pure-ftpd-stop.pl «Full Path to configuration file> 
Configuration file path must be same as the one passed to pure-config.pl in the load script. 


NOTE: In iManager, load and unload the cluster resources. Pure-ftpd instances must be loaded along 
with the shared NSS volumes. During the migration process, the pure-ftpd instances alongwith the 
associated shared volumes are moved across the cluster nodes. 


Migrating Pure-FTPd From NetWare to Linux 


You can also migrate an existing FTP server configuration from a NetWare server to OES 2015 SP1. 
For migration instructions and a brief FAQ, see "Migrating FTP to OES 2015 SP1" in the OES 2015 
SP1: Migration Tool Administration Guide. 


NCP Implementation and Maintenance 
If you have installed the NCP server for OES, eDirectory/Novell Client users can access files on the 


OES 2015 SP1 server with no additional configuration. 


The implementation information in the following sections can help you get started with NCP on OES 
2015 SP1 servers. 


¢ Section 18.6.1, "The Default NCP Volume,” on page 211 
¢ Section 18.6.2, “Creating NCP Home and Data Volume Pointers,” on page 211 
¢ Section 18.6.3, “Assigning File Trustee Rights,” on page 211 
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* Section 18.6.4, “NCP Caveats,” on page 211 
* Section 18.6.5, "NCP Maintenance," on page 212 


The Default NCP Volume 


The NCP Server for OES enables NCP access to NCP and NSS volumes defined on the OES server. 
When you install the NCP server, the installation creates one NCP volume named SYS: that maps to 
the /usr/novell/sys folder on the OES server. 


This NCP volume contains LOGIN and PUBLIC directories that, in turn, contain a small subset of the 
files traditionally found on a NetWare server in the directories with the same names. 


Creating NCP Home and Data Volume Pointers 


Initially, there are no NCP home directories or data volumes available to Novell Clients that attach to 
an OES server. 


For existing eDirectory users: If you want users to have NCP home or data directories on the 
server, you must decide where you want these directories to reside on the server's partitions and then 
create NCP volumes by using the NCPCON utility at the terminal prompt. 


For example, if you wanted to create an NCP volume (pointer) named HOME and mount it to the /usr 
folder on the Linux server, you would enter the following command at the command prompt: 


ncpcon create volume HOME /usr 


After issuing this command, when a Novell Client attaches to the OES server, the HOME: volume 
appears along with the SYS: volume created by the installation. 


For new eDirectory users: If you create an NCP or NSS volume on the server prior to creating 
users, then you have the option of specifying that volume in iManager as the location of the home 
directory for the new users. 


IMPORTANT: NCP Volume pointers are always created with uppercase names (HOME: , SYS: , etc.) 
regardless of the case specified when the volume pointers are created. 


Assigning File Trustee Rights 


You can use the same methods for assigning file trustee rights on NCP volumes on OES servers that 
you use when assigning them on NetWare. For example, the Novell Client can be used by anyone 
with the Access Control right on the volume, or the root user can use the ncpcon utility » rights 
command at a command prompt to administer NCP trustee rights. See "Managing File System 
Trustees, Trustee Rights, and Attributes on NCP Volumes’in the OES 2015 SP1: NCP Server for 
Linux Administration Guide. (The ncpcon rights command is related to but not the same as the 
rights utility used to manage trustees on NSS volumes.) 


NCP Caveats 


Cross-protocol file locking (CPL) is enabled by default on all new servers with NCP installed. For 
more information, see Section 3.8.6, “Cross-Protocol File Locking Might Need To Be Reconfigured if 
AFP or CIFS Is Functioning on an NCP Server,” on page 41. 
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NCP Maintenance 


Because NCP provides Novell Client access to files on NetWare and OES servers, the service is 
covered by maintenance tasks that apply to file systems on these servers. For information on 
maintaining file services, see "storage, file systems, & databases (http://www.novell.com/ 
documentation/oes11/index.html#cat_stor-file-systems-databases)” in the online documentation. 


NetStorage Implementation and Maintenance 


The following sections are provided only as introductory information. For more information about 
using NetStorage, see the OES 2015 SP1: NetStorage Administration Guide for Linux. 

¢ Section 18.7.1, "About Automatic Access and Storage Locations,” on page 212 

* Section 18.7.2, "About SSH Storage Locations," on page 212 

* Section 18.7.3, "Assigning User and Group Access Rights," on page 213 

* Section 18.7.4, "Authenticating to Access Other Target Systems," on page 213 

* Section 18.7.5, "NetStorage Authentication Is Not Persistent by Default," on page 213 

* Section 18.7.6, "NetStorage Maintenance," on page 214 


About Automatic Access and Storage Locations 


The inherent value of NetStorage lies in its ability to connect users with various servers and file 
Systems. Some connections are created automatically depending on the OES platform where 
NetStorage is installed. Other connections must be created by the network administrator. 


NetStorage provides automatic access to: 


* NSS volumes on the same server that use the default mount point (/media/nss) 
* User Home directories that are specified in eDirectory on NCP or NSS volumes. 


* Drive mapping locations in login scripts of the user logging in (if the NCP Server for Linux is 
running on the server) 


Administrators can create storage locations to storage on any of the target servers illustrated in 
Figure 18-3 on page 189, including Dynamic Storage Technology (DST) volume pairs and Distributed 
File Services (DFS). For instructions on creating Storage Locations, see "Creating a Storage Location 
Object" in the OES 2015 SP1: NetStorage Administration Guide for Linux. 


About SSH Storage Locations 


If you plan to use SSH storage locations, be aware that by default any users who are enabled for 
Samba cannot access data stored at the SSH locations. Additional steps are required to grant 
simultaneous access to Samba and SSH. For more information, see Section 11.4, “SSH Services on 
OES 2015 SP1,” on page 92. 
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Assigning User and Group Access Rights 


Because NetStorage provides access to other file storage systems, the users and groups that access 
the other systems through NetStorage must be granted file and directory access on those systems. 


For example: 
* eDirectory users must exist in the eDirectory tree where the OES server resides and have 
access rights to the files and directories on the OES server. 


* Windows users must exist on the Windows systems and have the required access rights to the 
files and directories on those systems. 


* |f your users will access Samba files on an OES server, they must be enabled for LUM and 
Samba access on the OES server. For more information, see “OES Services That Require LUM- 
Enabled Access" on page 156. 


IMPORTANT: The eDirectory usernames and passwords that are used to authenticate to the 
NetStorage (OES) server must match the usernames and passwords defined on the target systems. 


Authenticating to Access Other Target Systems 


The OES installation establishes a primary authentication domain (or context) for NetStorage. To 
access any storage location, users must exist somewhere in this primary domain. When it receives 
an authentication request, NetStorage searches for the username in the context you specified during 
OES installation and in all its subcontexts. 


Authentication to other file systems is often controlled by other authentication domains. For example, 
you might create a storage location on the OES server that points to a legacy NetWare server that 
resides in a different eDirectory tree. To access this storage location, users must authenticate to the 
other tree. 


This means that you must specify an additional context in the NetStorage configuration as a non- 
primary authentication domain. 


When defining a non-primary authentication domain, you must 


* Ensure that the username and password in the non-primary domain matches the username and 
password in the primary domain. 


* Specify the exact context where User objects reside. In contrast to the way it searches in the 
primary authentication domain, NetStorage doesn't search the subcontexts of non-primary 
authentication domains. 


For more information about managing NetStorage authentication domains, see "Authentication 
Domains" in the OES 2015 SP1: NetStorage Administration Guide for Linux. 


NetStorage Authentication Is Not Persistent by Default 


By default, users must reauthenticate each time they access NetStorage in a browser. This is true 
even if another browser window is open and authenticated on the same workstation. 


The reason for this is that persistent cookies are not enabled by default. 


This setting can be changed. For more information, see "Persistent Cookies" in the OES 2015 SP1: 
NetStorage Administration Guide for Linux. 
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NetStorage Maintenance 


Your NetStorage installation can change as your network changes and evolves by providing access 
to new or consolidated storage locations. For information about the kinds of tasks you can perform to 
keep your NetStorage implementation current, see the OES 2015 SP1: NetStorage Administration 
Guide for Linux. 


Novell AFP Implementation and Maintenance 


To use the Novell implementation of AFP file services on your OES 2015 SP1 server, you must install 
the service by using the instructions in the OES 2015 SP1: Installation Guide (for a new installation) 
or install it after the initial OES installation, as explained in "Installing AFP after OES 2015 SP1 
Installation" in theOES 2015 SP1: Novell AFP for Linux Administration Guide. 


* Section 18.8.1, "Implementing Novell AFP File Services," on page 214 
* Section 18.8.2, “Maintaining Novell AFP File Services," on page 214 


Implementing Novell AFP File Services 


All eDirectory users can access the AFP file services on an OES 2015 SP1 server as they would any 
Macintosh server. 


Maintaining Novell AFP File Services 


Information on maintaining your AFP installation is found in theOES 2015 SP1: Novell AFP for Linux 
Administration Guide. 


Novell CIFS Implementation and Maintenance 


To use the Novell implementation of CIFS file services on your OES server, you must install the 
service by using the instructions in the OES 2015 SP1: Installation Guide (for a new installation) or 
install it after the initial OES installation, as explained in "Installing CIFS after the OES Installation" in 
the OES 2015 SP1: Novell CIFS for Linux Administration Guide. 

* Section 18.9.1, "Implementing Novell CIFS File Services," on page 214 


* Section 18.9.2, "Maintaining Novell CIFS File Services," on page 215 


Implementing Novell CIFS File Services 


All eDirectory users can access the CIFS file services on an OES 2015 SP1 server as they would any 
Windows workgroup server. 


Active Directory users can also be granted access through the NSS AD integration service, starting in 
OES 2015. 


For instructions on implementing Novell CIFS, see "Planning and Implementing CIFS" in the OES 
2015 SP1: Novell CIFS for Linux Administration Guide. 
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Maintaining Novell CIFS File Services 


Information on maintaining your CIFS installation is found in the OES 2015 SP1: Novell CIFS for 
Linux Administration Guide. 


Novell iFolder 3.9.2 Implementation and 
Maintenance 


The following implementation pointers are provided only as introductory information. To begin using 
Novell iFolder, see the Novell iFolder 3.9.2 Administration Guide. 

¢ Section 18.10.1, “Managing Novell iFolder 3.9.2," on page 215 

* Section 18.10.2, "Configuring Novell iFolder 3.9.2 Servers," on page 215 

* Section 18.10.3, "Creating and Enabling Novell iFolder 3.9.2 Users," on page 215 

* Section 18.10.4, "Novell iFolder 3.9.2 Maintenance," on page 215 


Managing Novell iFolder 3.9.2 


You manage Novell iFolder through the iFolder Management Console, which you can access directly 
or through iManager. For more information, see "Installing and Configuring iFolder Services" in the 
Novell iFolder 3.9.2 Administration Guide. 


Configuring Novell iFolder 3.9.2 Servers 


Before you let users log in to the Novell iFolder 3.9.2 server, be sure you complete all the setup tasks 
in "Installing and Configuring iFolder Services" (including "Configuring the iFolder Web Admin Server" 
if applicable) in theNovell iFolder 3.9.2 Administration Guide. 


Creating and Enabling Novell iFolder 3.9.2 Users 


To provide user access to Novell iFolder 3.9.2: 


1. Provision eDirectory User objects for iFolder 3.9.2. 
. Enable the User Account Policies for iFolder access. 
. (Optional) Enable Account Quotas (space limits) for the user accounts. 


. Create iFolders for users. 
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. Distribute the iFolder Client to users. 


For more information, see "Managing iFolder Users" in the Novell iFolder 3.9.2 Administration Guide. 


Novell iFolder 3.9.2 Maintenance 


As the Novell iFolder service load increases, you might need to increase the server capacity or add 
additional servers. For help, see "Installing and Configuring iFolder Services" in the Novell iFolder 
3.9.2 Administration Guide. 
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Samba Implementation and Maintenance 


To use the Novell implementation of Samba file services on your OES server, you must install the 
service by using the instructions in the OES 2015 SP1: Installation Guide (for a new installation) or 
install it after the initial OES installation, as explained in "Installing Novell Samba for OES" in the OES 
2015 SP1: Novell Samba Administration Guide. 


¢ Section 18.11.1, "Implementing Samba File Services,” on page 216 
¢ Section 18.11.2, "Maintaining Samba File Services," on page 216 


Implementing Samba File Services 


All users whose accounts have been enabled for Samba access can access the OES server as they 
would any Windows server. 


For instructions on implementing Samba, see "Installing Novell Samba for OES" in the OES 2015 
SP1: Novell Samba Administration Guide. 


Maintaining Samba File Services 


Information on maintaining your Samba installation is found in the OES 2015 SP1: Novell Samba 
Administration Guide. 
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19.1.1 


19.1.2 


Print Services 


Open Enterprise Server 2015 SP1 includes Novell iPrint, a powerful and easy-to-implement printing 
solution that provides print-anywhere functionality to network users. 


This section contains the following information: 


¢ Section 19.1, "Overview of Print Services,” on page 217 
* Section 19.2, "Planning for Print Services," on page 219 
¢ Section 19.3, “Coexistence and Migration of Print Services," on page 219 
¢ Section 19.4, "Print Services Implementation Suggestions,” on page 220 


¢ Section 19.5, "Print Services Maintenance Suggestions," on page 221 


Overview of Print Services 


Novell iPrint lets Linux, Macintosh, and Windows users 


* Quickly locate network printers through a Web browser. 
* Easily install and configure a located printer through a native printer installation method. 


* Print to installed printers from any location (including the Web) through an IP connection. 


The information in this section provides a high-level overview of Novell iPrint print services. It is 
designed to acquaint you with basic iPrint functionality so you understand the configuration steps you 
need to perform to provide iPrint print services, and understand how iPrint functions from the user's 
perspective. 

¢ Section 19.1.1, "Using This Overview,” on page 217 

« Section 19.1.2, "iPrint Components," on page 217 


¢ Section 19.1.3, "iPrint Functionality,” on page 218 


Using This Overview 


If you already know that you want to provide OES print services for your users and you understand 
how iPrint works, skip the overviews and continue with Section 19.2, "Planning for Print Services," on 
page 219. 


If you want to learn more about iPrint, continue with this overview section. 


iPrint Components 


A Novell iPrint installation consists of various components, most of which are represented by objects 
in your eDirectory tree: 


* Print Driver Store: This is a repository that stores the drivers on an OES server for your 
network printers. It is the first component you configure and is represented by an eDirectory 
object that you create. It corresponds to the Print Broker on NetWare. 


Print Services 217 


* Printer Drivers: These are the platform-specific printer drivers and PostScript Printer 
Description (PPD) files that are stored in the Driver Store and are installed on workstations when 
users select a target printer. Printer drivers and PPD files exist as file structures within the Driver 
Store and are not represented by objects in eDirectory. 


* Printer Objects: These are eDirectory objects you create that store information about the 
printers available through iPrint. The information stored in an object is used each time its 
associated printer is added to a workstation's list of available printers. 


* Print Manager: This is a daemon that runs on OES. It receives print jobs from users and 
forwards them to the target printer when it is ready. It is represented by and controlled through an 
eDirectory object that you can configure. 


* iPrint Client: This is a set of browser plug-ins. On Macintosh and Windows workstations it is 
automatically installed the first time it interacts with iPrint. On Linux workstations, it must be 
installed manually. The client is required on each platform to navigate through the iPrint Web 
pages, select a target printer, and install the print driver. 


19.13  iPrint Functionality 


Figure 19-1 describes how iPrint functions from a user workstation perspective. 


Figure 19-1 How iPrint Works 
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The following table explains the information illustrated in Figure 19-1. 
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Table 19-1 iPrint Functionality 


Access 


The iPrint Client must be installed 
on each workstation accessing 
iPrint services. 


A user needing to use a printer for 
the first time accesses the 
organization's print page on the 
Web. 


When the user selects the target 
printer, its platform-specific driver is 


Authentication 


You can require authentication for 
Windows users if needed. The 
option to require authentication is 
not available for Linux and 
Macintosh users. 


Although shown separately, 
eDirectory could be installed on the 
OES server. 


Printing Services 


Users with the iPrint Client installed 
and access to the OES server can 
install printer drivers and print to 
iPrint printers. 


By default, iPrint generates a printer 
list for the printers hosted on the 
server. 


A customized Web page lets users 
browse to the target printer by using 


automatically installed and 
configured. 


location lists and maps that you 
have previously created for the site 


1 ; . where the printer is located. 
After printer installation, users can 


print to the printer from any 
application. 


19.2 Planning for Print Services 


We recommend that you record your decisions in planning notes for future reference. 
Consider the following information as you plan your iPrint installation: 


* iPrint has no additional RAM requirements. 


* Most iPrint installations (even in large enterprises) do not require additional disk space for 
associated print job spooling. 


However, if you anticipate very heavy print usage and want to plan for additional disk space in 
that regard, the iPrint spooler area is located in the /var partition or directory structure on OES 
servers. 


* To finish planning your iPrint installation, refer to the information in "Novell iPrint" in the OES 
2015 SP1: Installation Guide 


19.3 Coexistence and Migration of Print Services 


If you select iPrint during the OES server installation, the iPrint software components are 
automatically installed on the server. Although the Common UNIX Printing System (CUPS) software 
is installed with the SLES 11 packages, CUPS is disabled to avoid port 631 conflicts. 


For information on upgrading from NetWare queue-based printing, Novell Distributed Print Services 
(NDPS), or previous versions of iPrint, see "Installing iPrint Software" in the NW 6.5 SP8: iPrint 
Administration Guide. 


For more information on configuring iPrint on OES, see "Installing and Setting Up iPrint on Your 
Server" in the OES 2015 SP1: iPrint Linux Administration Guide. 


Migrating iPrint services from a NetWare server to an OES 2015 SP1 server is supported by the OES 
2015 SP1 Migration Tool. For more information, see "Migrating iPrint to OES 2015 SP1" in the OES 
2015 SP1: Migration Tool Administration Guide. 
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19.4 


19.4.1 


Print Services Implementation Suggestions 


This section provides only summary implementation information. For complete iPrint documentation, 
see the OES 2015 SP1: iPrint Linux Administration Guide. 


* 


* 


* 


Section 19.4.1, "Initial Setup," on page 220 
Section 19.4.2, "Implementation Caveats," on page 221 


Section 19.4.3, "Other Implementation Tasks," on page 221 


Initial Setup 


After your OES server is installed, you must do the following to complete your iPrint installation: 


1 


Create a Driver Store to store the print drivers. 


This eDirectory object stores the drivers for your network printers. Each Printer object you create 
for your network needs to reference a printer driver in Driver Store. When users subsequently 
install printers, the correct drivers for the platform running on their workstation are downloaded 
from the Driver Store and installed. 


You create the Driver Store through iManager. For specific instructions, see "Creating a Driver 
Store" in the OES 2015 SP1: iPrint Linux Administration Guide 


Add a printer driver to the Driver Store for each printer/platform combination needed. 


For example, If you have Windows XP, Windows 7, and Novell Linux Desktop (NLD) 
workstations on your network and you have four different printer types, you need to add four 
printer drivers for each platform (a total of 12 printer drivers) to the Driver Store. 


You add printer drivers to the store through iManager. For specific instructions, see "Updating 
Printer Drivers" in the OES 2015 SP1: iPrint Linux Administration Guide 


Create a Print Manager object. 


The Print Manager receives print jobs from users and forwards them to the target printer when it 
is ready. The Print Manager must be running for you to create Printer objects. 


The Print Manager is an object you create in eDirectory and is usually started and stopped 
through iManager. 


You create the Print Manager object through iManager. For specific instructions, see "Creating a 
Print Manager” in the OES 2015 SP1: iPrint Linux Administration Guide 


Create Printer objects. 


You must create a Printer object for each printer you want users to access through iPrint. These 
objects store information about the printer that is used each time the printer is installed on a 
workstation. 


You create Printer objects through iManager. For specific instructions, see "Creating a Printer" in 
the OES 2015 SP1: iPrint Linux Administration Guide 


(Optional) Create location-based, customized printing Web pages. 


By default, each iPrint installation includes the creation of a Default Printer List Web page that 
users can access to install iPrint printers. 


You have the option of enhancing the browsing experience by creating location-based printing 
Web pages that feature either lists of printers by location, maps of the buildings showing each 
printer, or a combination of both. 


If your organization is located in a building with multiple floors or even at multiple sites, providing 
location-based print Web pages can greatly simplify printing for your users. 
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Your iPrint installation contains the iPrint Map Designer to help you easily create location maps 
with clickable printer icons. For more information, see "Setting Up Location-Based Printing" in 
the OES 2015 SP1: iPrint Linux Administration Guide 


6 Provide instructions to users for accessing iPrint printers. 


After performing the steps above, your network is ready for iPrint functionality. You need only tell 
users how to access your printing Web pages; Novell iPrint does the rest. 


19.4.2 Implementation Caveats 


There are a few implementation caveats relating to iPrint on Linux. See "iPrint" on page 69. 


19.4.3 Other Implementation Tasks 


In addition to the tasks described in Section 19.4.1, "Initial Setup," on page 220, there are additional 
tasks you might want or need to consider. To see a list of potential tasks, refer to the "Print Services 
(http:/Awww.novell.com/documentation/oes11/index.html#cat_iprint)” links in the OES online 
documentation. 


195 Print Services Maintenance Suggestions 


As you add printers to your network or move them to different locations, be sure to update your iPrint 
installation to reflect these changes. 


After your installation is completed and users are printing, you can monitor print performance by using 
the information located in "Using the Print Manager Health Monitor" in the OES 2015 SP1: iPrint Linux 
Administration Guide 


For more information on iPrint and its functionality within OES, see the "Print Services (http:// 
www.novell.com/documentation/oes11/index.htmlZcat iprint)" links in the online documentation. 
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Web Services 


The Web and application services in Open Enterprise Server 2015 SP1 support the creation and 
deployment of Web sites and Web applications that leverage the widespread availability of Internet- 
based protocols and tools. 


With the proper Web components in place, a server can host dynamic Web sites where the content 
changes according to selections made by the user. You can also run any of the hundreds of free Web 
applications that can be downloaded from the Internet. Web and application services make it easy to 
build your own dynamic Web content and create customized Web database applications. 


See the OES 2015 SP1: Web Services and Applications Guide. 


Apache 
OES 2015 SP1 includes Apache 2.2, the most popular Web server on the Internet. 


For additional information, see the Apache.org Web site (http://httpd.apache.org/docs/2.2/). 


Tomcat 


OES 2015 SP1 includes Tomcat 6.0, which is used to run basic Java servlet and JavaServer Pages 
(JSP) applications. 


For information, see the Apache Tomcat 6.0 Web site (http://tomcat.apache.org/tomcat-6.0-doc/ 
index.html). 
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Security 


This section contains the following topics: 


¢ Section 21.1, "Overview of OES Security Services,” on page 225 

¢ Section 21.2, "Planning for Security," on page 227 

¢ Section 21.3, "Configuring and Administering Security," on page 231 

¢ Section 21.4, "DES 2015 SP1 and Security Scanners,” on page 231 

¢ Section 21.5, "Links to Product Security Considerations," on page 231 
¢ Section 21.6, “Links to Anti-Virus Partners," on page 232 


21.1 Overview of OES Security Services 


This section provides specific overview information for the following key OES components: 


¢ Section 21.1.1, "Application Security (AppArmor)," on page 225 
¢ Section 21.1.2, “NSS Auditing Engine,” on page 225 

¢ Section 21.1.3, "Encryption (NICI)," on page 226 

¢ Section 21.1.4, "General Security Issues," on page 227 


21.1.1 Application Security (AppArmor) 


Novell AppArmor provides easy-to-use application security for both servers and workstations. You 
specify which files a program can read, write, and execute. 


AppArmor enforces good application behavior without relying on attack signatures and prevents 
attacks even if they are exploiting previously unknown vulnerabilities. 


For more information, see the Novell AppArmor Documentation Web site (http://www.novell.com/ 
documentation/apparmor/index.html). 


21.1.2 NSS Auditing Engine 


OES includes the NSS Auditing Engine, which is installed by default with NSS. 


The auditing engine provides an interface for auditing client applications, such as Novell Sentinel and 
various third-party products to access. Information about the auditing engine SDK is available on the 
Novell Web site (http://developer.novell.com/wiki/index.php/NSS Auditing SDK). 


Using the SDK, client applications can be developed to audit various NSS file system operations on 
files and directories, including: 

* delete 

* create 

* open 


* close 
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* rename 

¢ link 

* metadata modified 

* trustee add/delete 

* inherited rights modified 


Novell Sentinel Server 90-Day Free Trial 


Novell Sentinel Log Manager runs on a 64-bit SLES 11 host. You can download the suite from the 
Novell Download Web site (http://download.novell.com/Download?buildidzyDnJELwauAo-). For 
installation and usage instructions, see the Novell Sentinel Readme and Release Notes included as a 
link on the download page. 


Third-Party Partner Applications 


For information about third-party partner applications that leverage the NSS Auditing Engine, see the 
OES partners' page. 


Encryption (NICI) 


The Novell International Cryptography Infrastructure (NICI) is the cryptography service for NetIQ 
eDirectory, NetIQ Modular Authentication Services (NMAS), NetIQ Certificate Server, NetIQ 
SecretStore, and TLS/SSL. 


Key Features 


NICI includes the following key features: 


* Industry standards: It implements the recognized industry standards. 
* Certified: It is FIPS-140-1 certified on selected platforms. 
¢ Cross-platform support: It is available on both OES platforms. 


* Governmental export and import compliance: It has cryptographic interfaces that are 
exportable from the U.S. and importable into other countries with government-imposed 
constraints on the export, import, and use of products that contain embedded cryptographic 
mechanisms. 


* Secure and tamper-resistant architecture: The architecture uses digital signatures to 
implement a self-verification process so that consuming services are assured that NICI has not 
been modified or tampered with when it is initialized. 


Never Delete the NICI Configuration Files 


In the early days of NICI development, some NICI problems could be solved only by deleting the NICI 
configuration files and starting over. The issues that required this were solved years ago, but as is 
often the case, the practice persists, and some administrators attempt to use this as a remedy when 
they encounter a NICI problem. 


No one should ever delete the NIC! configuration files unless they are directly told to do so bya 
member of the NICI development team. And in that rare case, they should be sure to back up the files 
before doing so. Failure to do this makes restoring NICI impossible. 
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21.2 


21.2.1 


More Information 


For more information on how to use NICI, see the Novell International Cryptographic Infrastructure 
(NICI) 2.7.6 Administration Guide. 


General Security Issues 


In addition to the information explained and referenced in this section, the OES online documentation 
contains links to "security issues" (http://www.novell.com/documentation/oes11/ 
index.htmlZcat security). 


Planning for Security 


This section discusses the following topics. For additional planning topics, see the Security section in 
the OES online documentation (http://www.novell.com/documentation/oes11/ 
index.htmlZcat security). 


* Section 21.2.1, "Comparing the Linux and the Novell Trustee File Security Models," on page 227 
* Section 21.2.2, "User Restrictions: Some OES Limitations," on page 229 
* Section 21.2.3, "Ports Used by OES 2015 SP1,” on page 229 


Comparing the Linux and the Novell Trustee File Security 
Models 


The Novell Trustee and Linux (POSIX) security models are quite different, as presented in Table 21-1. 


Table 21-1 POSIX vs. NSS/NCP File Security Models 


Feature POSIX / Linux Novell Trustee Model on OES 
Administrative principles Permissions are individually controlled and Trustee assignments are made to 
managed for each file and subdirectory. directories and files and flow down 


: from directories to everything below 
Because of the nature of the POSIX security — unless specifically reassigned. 


model, users usually have read rights to most 
of the system. 


To make directories and files private, 
permissions must be removed. 


For more information on making existing 
directories private, see Section 18.4.2, 
“Providing a Private Work Directory,” on 
page 201. 


Security 227 


228 


Feature 


Default accessibility 


POSIX / Linux 


Users have permissions to see most of the file 
system. 


The contents of a few directories, such as the 
/root home directory, can only be viewed by 
the root user. 


Some system configuration files can be read 
by everyone, but the most critical files, such as 
/etc/fstab, can only be read and modified 
by root. 


Novell Trustee Model on OES 


Users can see only the directories 
and files for which they are trustees 
(or members of a group that is a 
trustee). 


Home directories—an 
example of default 
accessibility 


By default, all users can see the names of 
directories and files in home directories. 


During LUM installation, you can specify that 


newly created home directories will be private. 


For more information on making existing home 
directories private, see Section 18.4.2, 
"Providing a Private Work Directory," on 

page 201. 


By default, only the system 
administrator and the home 
directory owner can see a home 
directory. Files in the directory are 
secure. 


If users want to share files with 
others, they can grant trustee 
assignments to the individual files, 
or they can create a shared 
subdirectory and assign trustees to 
it. 


Inheritance from parents 


Nothing is inherited. 


Granting permission to a directory or file 
affects only the directory or file. 


Rights are inherited in all child 
subdirectories and files unless 
specifically reassigned. 


A trustee assignment can 
potentially give a user rights to a 
large number of subdirectories and 
files. 


Privacy 


Because users have permissions to see most 
of the file system for reasons stated above, 
most directories and files are only private 
when you make them private. 


Directories and files are private by 
default. 


Subdirectory and file 
visibility 


Permissions granted to a file or directory apply 
to only the file or directory. Users can't see 
parent directories along the path up to the root 
unless permissions are granted (by setting the 
UID, GID, and mode bits) for each parent. 


After permissions are granted, users can see 
the entire contents (subdirectories and files) of 
each directory in the path. 


When users are given a trustee 
assignment to a file or directory, 
they can automatically see each 
parent directory along the path up 
to the root. However, users can't 
see the contents of those 
directories, just the path to where 
they have rights. 


When an NCP volume is created on a Linux POSIX or NSS volume, some of the behavior described 
above is modified. For more information, see the OES 2015 SP1: NCP Server for Linux 
Administration Guide, particularly the “NCP on Linux Security" section. 
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21.2.3 


User Restrictions: Some OES Limitations 


Seasoned NetWare administrators are accustomed to being able to set the following access 
restrictions on users: 

* Account balance restrictions 

* Address restrictions 

¢ Intruder lockout 

* Login restrictions 

+ Password restrictions 

* Time restrictions 


Many of the management interfaces that set these restrictions (iManager, for example), might seem 
to imply that these restrictions apply to users who are accessing an OES server through any protocol. 


This is generally true, with two important exceptions: 


* Maximum number of concurrent connections in login restrictions 


* Address restrictions 


These two specific restrictions are enforced only for users who are accessing the server through 
NCP. Connections through other access protocols (for example, HTTP or CIFS) have no concurrent 
connection or address restrictions imposed. 


For this reason, you probably want to consider not enabling services such as SSH and FTP for LUM 
when setting up Linux User Management. For more information on SSH and LUM, see Section 11.4, 
"SSH Services on OES 2015 SP1,” on page 92. 


For more information on Linux User Management, see "Linux User Management: Access to Linux for 
eDirectory Users" on page 153. For more information on the services that can be PAM-enabled, see 
Table 15-2 on page 157. 


Ports Used by OES 2015 SP1 


The ports used by OES 2015 SP1 services are listed in Table 21-3. 
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Table 21-2 Open Enterprise Server Services and Ports 


Service 


Domain Services for Windows 


NetlQ eDirectory 


iManager 


iPrint 


Novell Identity Translator 


Novell AFP 


Novell CIFS 


Novell DHCP 


Novell DNS 


Novell FTP 
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Default Ports 


1636 (LDAPS) 

1389 (LDAP) 

88 (Kerberos TCP and UDP) 

135 (RPC Endpoint Manager TCP and UDP) 
1024 - 65535 (RPC Dynamic Assignments TCP) 
3268 (Global Catalog LDAP TCP) 

3269 (Global Catalog LDAP over SSL TCP) 

123 (Network Time Protocol UDP) 

137 (NetBIOS Name Service TCP and UDP) 
138 (NetBIOS Datagram Service TCP and UDP) 
139 (NetBIOS Session Service TCP and UDP) 
8025 (Domain Service Daemon TCP) 

445 (Microsoft-DS traffic TCP and UDP) 


389 (LDAP) 
636 (secure LDAP) 


IMPORTANT: The scripts that manage the common proxy 
user require port 636 for secure LDAP communications. 


8028 (HTTP for iMonitor) 
8030 (secure HTTP for iMonitor) 
524 (NCP) 


80 (HTTP) 
443 (secure HTTP) 


80 (HTTP) 
443 (secure HTTP) 
631 (IPP) 


3268 
389 


548 


139 (Netbios) 
445 (Microsoft-ds) 


67 


953 (secure HTTP) 
53 (TCP) 
53 (UDP) 
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21.4 


21.5 


Service 


Novell Information Portal 


Novell NetWare Core Protocol (NCP) 


Novell Remote Manager 


NURM 


SFCB 


Samba 


Secure Shell 
Storage Management Services (Backup) 


Time Synchronization 


Default Ports 


* 


80 (HTTP) 
443 (secure HTTP) 


524 


8008 (HTTP) 
8009 (secure HTTP) 


80 
443 


5988 (HTTP) 
5989 (secure HTTP) 


139 (Netbios) 
445 (Microsoft-ds) 


22 
40193 (smdr daemon) 


123 (Network Time Protocol UDP) 


Configuring and Administering Security 


For a list of configuration and administration topics, see the Security section in the OES online 
documentation (http://www.novell.com/documentation/oes11/index.htmlzccat security). 


OES 2015 SP1 and Security Scanners 


Novell software development processes include the performance of regular and rigorous security 
scans. All issues that are discovered as part of these scans are resolved prior to product releases. 


As you perform security scans inside your organization, if you discover security issues that involve 
OES 2015 SP1 or other Novell products, and if you are unable to resolve them, please contact Novell 


Support for help. 


Links to Product Security Considerations 


The following product documentation contains additional security information: 


Table 21-3 Security Consideration Links 


Product/Technology 


AppArmor 


Security Considerations Section Link 


Novell AppArmor Administration Guide (http:// 
www.novell.com/documentation/apparmor/ 
apparmor201 sp10 admin/data/ 

book apparmor admin.html) 
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Product/Technology 


Domain Services for Windows 


Security Considerations Section Link 


OES 2015 SP1: Novell Domain Services for Windows 
Security Guide 


Dynamic Storage Technology 


"Security Considerations" in the OES 2015 SP1: 
Dynamic Storage Technology Administration Guide 


eDirectory "Security Considerations" in the Net/Q eDirectory 8.8 
SP8 Administration Guide 
File Systems OES 2015 SP1: File Systems Management Guide 


(information throughout the guide) 


Identity Manager 4.0.2 


"Security Best Practices" in the NetIQ Identity 
Manager Security Guide. 


iPrint for OES 


"Setting Up a Secure Printing Environment" in the OES 
2015 SP1: iPrint Linux Administration Guide 


Linux User Management 


"Security Considerations" in the OES 2015 SP1: Linux 
User Management Administration Guide 


Novell AFP "Security Guidelines for AFP" in theOES 2015 SP1: 
Novell AFP for Linux Administration Guide 
Novell CIFS "Security Guidelines for CIFS” in the OES 2015 SP1: 


Novell CIFS for Linux Administration Guide. 


Client for Open Enterprise Server 


Security Considerations in the Client for Open 
Enterprise Server Administration Guide 


Novell Remote Manager for OES 


"Security Considerations" in the OES 2015 SP1: 
Novell Remote Manager Administration Guide 


Novell Storage Services 


"Securing Access to NSS Volumes, Directories, and 
Files" and "Security Considerations" in the OES 2015 
SP1: NSS File System Administration Guide for Linux 


Novell iFolder 3.9.2 


Novell iFolder 3.9.2 Security Administration Guide 


OES 2015 SP1 Installation 


"Security Considerations" in the OES 2015 SP1: 
Installation Guide 


OES 2015 SP1 Migration Tools 


"Security Considerations for Data Migration" in the 
OES 2015 SP1: Migration Tool Administration Guide 


SuSEfirewall2 


“Masquerading and Firewalls" (http://www.suse.com/ 
documentation/sles11/book security/data/ 

cha security firewall.html) in the SLES 11 SP4 
Security Guide (http://www.suse.com/documentation/ 
sles11/book security/data/book security.html) 


Links to Anti-Virus Partners 


See the Partners and Communities page on Novell.com (http://www.novell.com/products/ 
openenterpriseserver/partners communities.html). 
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22.1.1 


Certificate Management 


By default, all SUSE Linux Enterprise Server (SLES) servers include self-generated server 
certificates to secure data communications with the servers. These certificates are self-signed and do 
not comply with the X.509 RFCs. They are provided only as a stop-gap and should be replaced as 
soon as possible by a certificate from a trusted Certificate Authority. 


Unfortunately, many organizations ignore the vulnerabilities to mischievous or even malicious attacks 
that are created by not replacing these temporary certificates. Some of the reasons for this are 


* Administrators lack the knowledge required. 
* Certificate maintenance can require a significant investment of time and effort. 


* Obtaining third-party certificates for each server is expensive. 


The problems are compounded by the fact that X.509 certificates are designed to expire regularly and 
should be replaced shortly before they do. 


Open Enterprise Server 11 includes solutions that address each of these issues at no additional 
expense. 


This section discusses the certificate management enhancements available in OES and how simple 
and straightforward it is to utilize them. 


¢ Section 22.1, “Overview,” on page 233 
¢ Section 22.2, "Setting Up Certificate Management,” on page 235 
¢ Section 22.3, "If You Don't Want to Use eDirectory Certificates," on page 238 


Overview 


The following sections outline how OES lets you automate certificate management for OES and all 
HTTPS services: 


¢ Section 22.1.1, “SLES Default Certificates," on page 233 
¢ Section 22.1.2, “OES Certificate Management,” on page 234 
¢ Section 22.1.3, “Multiple Trees Sharing a Common Root,” on page 235 


SLES Default Certificates 


By default, HTTPS services on SLES 11 SP4 are configured to use two files that are located in /etc/ 
ssl/servercerts and are protected so that only root and some specific groups can read them: 


* serverkey.pem: This contains the server's raw private key. 


* servercert.pem: This contains the server's certificates. 


OES services, such as Apache, OpenWBEM, and Novell Remote Manager, are also configured to 
use these certificates. 
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22.1.2 OES Certificate Management 


OES enhances certificate management as follows: 


¢ "Installation of eDirectory Certificates" on page 234 
+ "What Is Installed Where" on page 234 

* "NetlQ Certificate Server" on page 235 

¢ "Server Self-Provisioning" on page 235 

+ “PKI Health Check" on page 235 


Installation of eDirectory Certificates 
As you install eDirectory and OES, by default all HTTPS services are configured to use eDirectory 
certificates. This means that eDirectory is established as the Certificate Authority for the tree you are 


installing into, and it will generate keys and certificates for the server and replace the installed SLES 
certificates with the eDirectory certificates. 


What Is Installed Where 


Key and certificate files are installed in the following locations: 


Table 22-1 File Locations 


Location Details 
/etc/ssl/certs This is the default location of trusted root certificates for clients on 
the server. 


Most of the applications on the server are configured to use this 
directory. For example, the LDAP client uses one or more of the 
trusted certificates in this directory when establishing a secure 
LDAP connection. 


The OES installation copies the eDirectory tree CA's certificate 
(eDirCACert.pem) here, thereby establishing the CA as a trusted 
root. 


Everyone (other) has rights to read the contents of this directory. 


/etc/ssl/servercerts The standard location for the server's raw private key 
(serverkey. pem) and certificates (servercert.pem). 


Applications on the server, including OES applications, are 
configured to point to the files in this directory. 


Only root and some specific groups can read the files in this 
directory. 


/etc/opt/novell/certs This directory contains the eDirectory CA certificate in both DER 
and PEM formats for use by applications that need them. The files 
are named SSCert . der and SSCert.pem, respectively. 


For example, when PKI Health Check runs, it installs the CA 
certificate in the Java Keystore in DER format if the certificate 
needs replacing. 
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NetIQ Certificate Server 


The component that generates eDirectory keys and certificates is the NetIQ Certificate Server. 


This certificate server provides public key cryptography services that are natively integrated into 
NetIQ eDirectory. You can use the server to mint, issue, and manage both user and server certificates 
to protect confidential data transmissions over public communications channels such as the Internet. 


For complete information on the NetIQ Certificate Server, see the NetIQ Certificate Server 
Administration Guide. 


Server Self-Provisioning 


When activated, Server Self-Provisioning lets server objects in eDirectory create their own 
certificates. You must activate this option if you want PKI Health Check to automatically maintain your 
server certificates. 


For more information on this feature, see “X.509 Certificate Self-Provisioning" in the NetIQ Certificate 
Server Administration Guide. 


PKI Health Check 


The PKI health check runs whenever the certificate server starts. 


If you have enabled Server Self-Provisioning, the health check routine automatically replaces server 
certificates when any of the following are detected: 

* The certificates don't exist. 

* The certificates have expired. 

* The certificates are about to expire. 

* The IP or DNS information on the certificates doesn't match the server configuration. 


* The Certificate Authority (CA) that issued the certificate is different from the CA currently 
configured. 


For more information on this feature, see “PKI Health Check” in the Net/Q Certificate Server 
Administration Guide. 


221.3 Multiple Trees Sharing a Common Root 


The Organizational CA can be configured to act as a sub-CA. This lets multiple trees share a 
common root certificate. The root certificate can be stored in a physically protected tree. It can also 
integrate with a third-party PKI. For more information, see "Subordinate Certificate Authority" in the 
NetIQ Certificate Server Administration Guide. 
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Use the information in the following sections to help you set up certificate management as you install 
OES. 


¢ Section 22.2.1, "Setting Up Automatic Certificate Maintenance,” on page 236 


¢ Section 22.2.2, “Eliminating Browser Certificate Errors," on page 236 


Certificate Management 235 


22.2.1 


22.2.2 


Setting Up Automatic Certificate Maintenance 


To set up your server so that HTTPS services use eDirectory certificates, you must specify the Use 
eDirectory Certificates for HTTP Services option while installing or upgrading eDirectory. 


This installs eDirectory keys and certificates on the server, but it does not configure the server to 
automatically replace the certificates when they expire. Automatic maintenance requires that Server 
Self-Provisioning be enabled as follows: 


1 On the server you are configuring, in iManager > Roles and Tasks, click the NetIQ Certificate 
Server > Configure Certificate Authority option. 
2 Click Enable server self-provisioning. 


This causes automatic certificate replacement for the conditions described in "PKI Health Check" 
on page 235. 


IMPORTANT: If you enable Server Self-Provisioning in an OES tree and you have created a 
CRL configuration object but not yet configured any CRL distribution points, the PKI Health 
Check might replace the default certificates every time it runs. 


To avoid this, you can either 


* Finish configuring the CA's CRL capability by creating one or more CRL Distribution Points 
by using iManager's Configure Certificate Authority task. 


or 


* Delete any CRL Configuration objects, for example CN=One - Configuration. CN=CRL 
Container.CN=Security. 


3 If you also want the CA certificate to be replaced if it changes or expires, click the Health Check 
- Force default certificate creation/update on CA change option. 


Eliminating Browser Certificate Errors 


Because the Internet Explorer and Mozilla Firefox browsers don’t trust eDirectory certificate 
authorities by default, attempts to establish a secure connection with OES servers often generate 
certificate errors or warnings. 


These are eliminated by importing the eDirectory tree CA's self-signed certificate into the browsers. 
Complete the instructions in the following sections as applicable to your network. 


+ “Exporting the CA's Self-Signed Certificate" on page 236 
* "Importing the CA Certificate into Mozilla Firefox on Linux” on page 237 
* "Importing the CA Certificate into Mozilla Firefox on Windows" on page 237 


+ "Importing the CA Certificate into Internet Explorer" on page 237 


Exporting the CA's Self-Signed Certificate 


1 Launch Novell iManager. 
2 Log into the eDirectory tree as the Admin user. 


3 Select the Roles and Tasks menu, then click NetIQ Certificate Server > Configure Certificate 
Authority. 


4 Click the Certificates tab, then select the self-signed certificate. 
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5 Click Export. 


6 Deselect Export Private Key. 


10 
11 


The Export Format changes to DER. 
Click Next. 


Click Save the Exported Certificate and save the file to the local disk, noting the filename and 
location if they are indicated. 


Click Close » OK. 
Find the file you just saved. By default it is usually on the desktop. 
Complete the instructions in the follow sections that apply to your browsers. 


Importing the CA Certificate into Mozilla Firefox on Linux 


o 0 fF O&O NM HM 


Launch Firefox. 

Click Edit > Preferences > Advanced. 
Select the Encryption tab. 

Click View Certificates. 

Select the Authorities tab, then click Import. 


Browse to the certificate file you downloaded in "Exporting the CA's Self-Signed Certificate" on 
page 236 and click Open. 


Select Trust this CA to identify Web sites, then click OK » OK » Close. 


Firefox now trusts certificates from the servers in the tree. 


Importing the CA Certificate into Mozilla Firefox on Windows 
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Launch Firefox. 

Click Tools » Options » Advanced. 

Select the Encryption tab. 

Click View Certificates. 

Select the Authorities tab, then click Import. 


Browse to the certificate file you downloaded in "Exporting the CA's Self-Signed Certificate" on 
page 236 and click Open. 


Select Trust this CA to identify Web sites, then click OK » OK » OK. 
Firefox now trusts certificates from the servers in the tree. 


Importing the CA Certificate into Internet Explorer 


0 à OO N HP 


Launch Internet Explorer. 

Click Tools > Internet Options. 

Select the Content tab. 

Click Certificates. 

Click Import. 

The Certificate Import Wizard launches. 
Click Next. 
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7 Click Browse, 


8 In the Files of Type drop-down list, select All Files(*.*), browse to the file you downloaded in 
"Exporting the CA's Self-Signed Certificate" on page 236, then click Open. 


9 Click Next. 
10 Click Next. 
Choose the default, Automatically select the certificate store based on the type of certificate. 
11 Click Finish » Yes » OK. 
Internet Explorer now trusts certificates from the servers in the tree. 


22.3 If You Don't Want to Use eDirectory Certificates 


For most organizations, the eDirectory certificate solution in OES is an ideal way to eliminate the 
security vulnerabilities mentioned at the beginning of this chapter. However, some administrators, 
such as those who have third-party keys installed on their servers, probably want to keep their 
installed certificates in place. 


You can prevent the use of eDirectory certificates for HTTPS services by making sure that the option 
to use them is not selected on the first eDirectory configuration page. 


238 Certificate Management 


Adding Services to OES Servers 


You can add services to OES servers after they are installed. 


OES is a set of services that can be either added to an existing server or installed at the same time as 
SUSE Linux Enterprise Server. After OES services are added, we refer to the server as an OES 
server. 


To add OES services to an OES 2015 SP1 server, follow the instructions in "Installing or Configuring 
OES 2015 SP1 on an Existing Server” in the OES 2015 SP1: Installation Guide. 
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B.1 


B.2 


B.2.1 


Changing an OES 2015 SP1 
Server's IP Address 


The instructions in this section let you change the IP address assigned to an OES 2015 SP1 server 
and the services it hosts. 

¢ Section B.1, “Caveats and Disclaimers," on page 241 

¢ Section B.2, “Prerequisites,” on page 241 

¢ Section B.3, "Changing the Server's Address Configuration," on page 242 

¢ Section B.4, "Reconfiguring the OES Services,” on page 242 

¢ Section B.5, "Repairing the eDirectory Certificates," on page 243 

¢ Section B.6, “Completing the Server Reconfiguration,” on page 243 

¢ Section B.7, “Modifying a Cluster,” on page 244 

¢ Section B.8, "Reconfiguring Services on Other Servers That Point to This Server,” on page 244 


Caveats and Disclaimers 


The instructions in this section assume that only the IP address of the server is changing. They do not 
cover changing the DNS hostname of the server. 


Prerequisites 


* Section B.2.1, "General," on page 241 
¢ Section B.2.2, “iPrint,” on page 242 
* Section B.2.3, "Clustering," on page 242 


General 


Before starting the process, be sure you know the following: 


C] Old IP Address: The server's IP address you are changing. 
C] New IP Address: The IP address the server will use after the change. 


C] Old Master Server Address: The IP address of the eDirectory™ server specified when the 
server was installed. 


By default this is also the LDAP server address for OES services installed on the server. 


C] New Master Server Address: The IP address of the eDirectory server that the server should 
point to after the change. The old and new addresses might be the same, but you will be 
required to enter both. 


C] Address of the Subnet for the New IP Address: This is a subnet address, not the subnet 
mask. For example, 192.168.2.0, not 255.255.255.0. 
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B.2.2 


B.2.3 


B.3 


iPrint 
If your network users connect to their printers through the print manager on this server, you might 
want to consider setting up iPrint Client Management (ICM) prior to the change. ICM lets you centrally 


configure the iPrint configuration for your users. For more information, see "Using iPrint Client 
Management' in the OES 2015 SP1: iPrint Linux Administration Guide. 


Clustering 


If the server is running Novell Cluster Services: 


1 Check your plans against the prerequisites for clusters in "IP Address Requirements" in the OES 


2015 SP1: Novell Cluster Services for Linux Administration Guide. 


2 Follow the instructions in "Changing the IP Addresses of Cluster Resources" in the same guide. 


Changing the Server's Address Configuration 


Log into the server you are reconfiguring as the root user. 


Copy the ipchange.sh script file found in /opt/novell/migration/sbin/serveridswap/ 
scripts/ipchange/nonplugin/ on any OES 2015 SP1 server, to the root (/) partition of the 
OES 2015 SP1 server you are reconfiguring. 


Open the YaST Control Center. 


4 In Network Devices select Network Card. 


Confirm that the Old IP address you listed in Section B.2.1, "General," on page 241 is in fact the 
IP address currently configured for the network card. You need this later in the process. 


Using the various dialog boxes associated with the network card configuration, change the card 
configuration to the new IP address settings you listed in Section B.2.1, "General," on page 241, 
changing each of the following as necessary: 


* |P Address 
* Subnet Mask 
* Router (Gateway) 
Close YaST, then continue with Section B.4, "Reconfiguring the OES Services," on page 242. 


B.4 Reconfiguring the OES Services 


1 Open a terminal prompt. 
2 Atthe terminal prompt, change to the root (/) directory, make the script executable, then run the 


script by entering the following commands: 

cd / 

chmod 744 ipchange.sh 

./ipchange.sh oldip newip oldmasterip newmasterip yes 


where oldip is the old IP address, newip is the new IP address, oldmasterip is the IP address of 
the eDirectory server specified when the server was installed, and newmasterip is the IP address 
of the new eDirectory server identified in Prerequisites above. 


The oldmasterip and the newmasterip can be the same IP address, but they must both be 
included in the command. In the script these are referred to as Remote edir/Idap addresses. 
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IMPORTANT: By default, the master eDirectory address (the eDirectory server specified at 
installation) is also the LDAP server address for OES services installed on the server. 


All services that are configured with the old master address as their LDAP address are 
reconfigured to use the new master address. On the other hand, if you specified a different 
LDAP server address for any of the installed services, and if that LDAP server's address is also 
changing, you need to manually reconfigure the services. 


To see the IP addresses that your services were originally configured to use, use a text editor to 
open the files in /etc/sysconfig/novell/. 


As the script runs, it changes all of the OES configuration files and does everything else that can 
be done automatically to change the IP address for all OES services. 


3 Type the Admin password when prompted. 
You might need to wait a few minutes for the LDAP server to restart. 


4 When the script finishes, restart the server by entering the following command at the terminal 
prompt: 


shutdown -r now 


B.5 Repairing the eDirectory Certificates 


1 Start iManager and click through the warnings about a DNS name mismatch. 


2 In the Login dialog box, type the Admin username and password, type the newmasterip address 
in the Tree field, then click Login. 


3 Click NetIQ Certificate Server > Repair Default Certificates. 


4 In Create Server Certificate » Step 1 of 3, browse to and select the server object for the server 
you are changing. 


5 Click OK » Next. 
6 In Step 2 of 3, click Next. 
7 Click Finish, then close the dialog box. 


B.6 Completing the Server Reconfiguration 


Some OES services require reconfiguration steps to be done manually. 
Complete the steps in the following sections as they apply to the server you are changing. 


¢ Section B.6.1, “DHCP,” on page 243 

¢ Section B.6.2, "iFolder," on page 244 

¢ Section B.6.3, “iPrint,” on page 244 

¢ Section B.6.4, "NetStorage," on page 244 


B.6.1 DHCP 


1 Make sure the DHCP configuration in eDirectory has a subnet declared for the new IP address. 


For instructions, see “Administering and Managing DHCP” in the OES 2015 SP1: DNS/DHCP 
Services for Linux Administration Guide. 
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B.6.2 


B.6.3 


iFolder 
See "Changing The IP Address For iFolder Services" in the Novell iFolder 3.9.2 Administration Guide. 
iPrint 


1 Using your favorite text editor, open the following configuration file: 


/etc/opt/novell/iprint/conf/DN_of_PSMipsmd.conf. 


where DN_of_PSM is the name of the Print Manager in eDirectory. 


2 Change any entries that list the old IP address to the new IP address. 


3 Restart the Print Manager by entering the following command at a terminal prompt: 


rcnovell-ipsmd restart 


IMPORTANT: Users that have accessed printers through the modified Print Manager will lose 
access to their printers. 


If you have set up iPrint Client Management on the server, you can automate the reconfiguration 
process. If not, users must reinstall the printers. 


For more information on iPrint Client Management, see “Using iPrint Client Management” in the 
OES 2015 SP1: iPrint Linux Administration Guide. 


B.6.4 NetStorage 


B.7 


B.8 


1 Ataterminal prompt, enter the following commands: 


/opt/novell/xtier/bin/xsrvcfg -D 
/opt/novell/xtier/bin/xsrvcfg -d newip -c AuthenticationContext 


where newip is the new IP address used throughout this section and AuthenticationContext is 
the eDirectory context for NetStorage users. NetStorage searches the eDirectory tree down 
from this container. If you want NetStorage to search the entire eDirectory tree, specify the 
root context. 


rcnovell-xregd restart 
rcnovell-xsrvd restart 
rcapache2 restart 


Modifying a Cluster 


If the server is running Novell Cluster Services™, complete the instructions in “Modifying the Cluster 
Configuration Information” in the OES 2015 SP1: Novell Cluster Services for Linux Administration 
Guide. 


Reconfiguring Services on Other Servers That 
Point to This Server 


If you have services on other servers that point to the old IP address for this server, be sure to 
reconfigure those services to point to the new IP address. 
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Updating/Patching OES 2015 SP1 
Servers 


One of a network administrator's biggest challenges is keeping installed software up-to-date on all 
servers and workstations. 


For instructions on setting up the update channel for each OES 2015 SP1 server and running the 
patch process, see “Updating (Patching) an OES 2015 SP1 Server” in the OES 2015 SP1: Installation 
Guide. 
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Quick Reference to OES User 
Services 


Use Table D-1 as a quick reference for providing your network users with instructions for accessing 
each OES service. 


Table D-1 OES User Services Quick Reference 


Services Access Method or URL Notes 
iPrint http://server ip address or dns name/ipp 
https://server ip address or dns name:443/ipp 
NetStorage For browser access, use: The WebDAV URL is case 
: sensitive. 
http: or https-//server ip or dns/netstorage 
For WebDAV access, use: 
http: or https://server ip or dns/oneNet/NetStorage 
Novell Client — 1. Install the Novell Client on a supported Windows or 
Linux workstation. 
For Macintosh support, see Novell Kanaka for Mac. 
2. Login to eDirectory. 
3. Access NCP volumes on NetWare or Linux that you 
have the appropriate file trustee rights to. 
Novell AFP In the Chooser, click Go and browse to the server. 
Novell CIFS Map a network drive in Windows, Linux, or Mac Finder. 
Create a Web Folder in Internet Explorer. 
For more information, see the OES 2015 SP1: Novell CIFS 
for Linux Administration Guide. 
Novell https://server ip address or dns namelifolder "ifolder" is the default name, but 
iFolder 3.x this can be customized by the 
Web Access administrator. 
server 
Novell http://server ip address or dns name:8008 Any LUM-enabled user can see 
Remote their directories and files on OES 
Manager servers. 
Samba Map a network drive in Windows Explorer. 


Create a Web Folder in Internet Explorer. 


For more information, see the OES 2015 SP1: Novell 
Samba Administration Guide. 
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OES 2015 SP1 Browser Support 


As a general rule, Open Enterprise Server 2015 SP1 management tools support the following 
browsers as they are available on the workstation platforms listed in "Client/Workstation OS Support" 
on page 251: 

* Mozilla Firefox 64-bit (latest 32- and 64-bit versions) on Windows, Macintosh, and Linux 

* Microsoft Internet Explorer 11 on windows 8.1 

* Microsoft Internet Explorer 11 (Win7sp1) 

* Microsoft Internet Explorer 10 (Win7sp1) 

* Apple Safari latest version on MAC 10.9 


* Google Chrome 21 or latest version on windows 7 Sp1 


Table E-1 provides service-specific links and information about browser support in OES. 


Table E-1 Browser Support in OES 


Management Tool Supported Browser Information Link 


iManager 2.7 + “Using a Supported Web Browser” in the NetiQ® iManager 
Administration Guide 


There are rendering differences for some iManager plug-ins between 
Internet Explorer and Mozilla-based browsers. For example, options that 
are accessed through tabs in IE are sometimes accessed through drop- 
down lists in Firefox. 


Also, iManager plug-ins might not work properly if the highest priority 
Language setting for your Web browser is set to a language other than 
one of iManager's support languages. 


To avoid problems, set the first language preference to a supported 


language. 
iMonitor * "System Requirements" in "Using NetIQ iMonitor" in the NetIQ 
eDirectory 8.8 SP8 Administration Guide 
IP Address Manager (NetWare) Same as Novell Remote Manager 
iPrint * "Supported Browsers for iPrint" in the OES 2015 SP1: iPrint Linux 
Administration Guide 
Novell iFolder 3.9.2 * "Web Browser' in the Novell iFolder 3.9.2 Administration Guide 
Novell Remote Manager * "System Requirements" in the OES 2015 SP1: Novell Remote 


Manager Administration Guide 


* "System Requirements" in the NW 6.5 SP8: Novell Remote Manager 
Administration Guide 


OpenSSH Manager (NetWare) * "Added Functionality" in the NW 6.5 SP8: OpenSSH Administration 
Guide 


TCP/IP Configuration (NetWare) Same as Novell Remote Manager 
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Client/ Workstation OS Support 


As a general rule, Open Enterprise Server 2015 or later services can be accessed and administered 
from workstations running the following operating systems: 


¢ SUSE Linux Enterprise Desktop 12 

* SUSE Linux Enterprise Desktop 11 SP3 and SP4 
* Windows 8.1 

* Macintosh 10.8, 10.9, and 10.10 


For specific information on a given service, consult the service documentation. 
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OES 2015 SP1 Service Scripts 


Novell Open Enterprise Server 2015 SP1 services rely on specific service scripts located in /etc/ 
init.d. The scripts used by OES 2015 SP1, some of which are standard Linux scripts, are listed in 


Table G-1. 


IMPORTANT: For managing OES 2015 SP1 services, we strongly recommend using the browser- 
based tools outlined in Section 11.1, "Overview of Management Interfaces and Services," on 

page 89. The browser-based tools provide error checking not available at the service-script level, and 
they ensure that management steps happen in the sequence required to maintain service integrity. 


Table G-1 OES Service Scripts in /etc/init.d 


Services Associated with Scripts Script Name Notes 

Apache Web server apache2 The rcapache2 symbolic link, which is by 
default part of the path, can be used to start, 
stop, and restart the Apache Web Server, 
rather than referencing the init script directly. 

CASA micasad This is the CASA daemon. 

Distributed File Services novell-dfs This lets you start and stop the VLDB service. 


DNS (NetlQ eDirectory enhanced) 


DNS (SUSE Linux Enterprise Server 11 
base) 


Domain services Daemon 


Dynamic Storage Technology 


novell-named 


named 


xadsd 


novell-shadowfs 


This works in connection with named to 
provide NetIQ eDirectory DNS services. 


This is the SLES 11 DNS service daemon. 


This script starts and stops the shadowfs 
daemon and the kernel module fuse. 


eDirectory ndsd This lets you start and stop eDirectory. It 
executes the /usr/sbin/ndsd binary. 

eDirectory SNMP support ndssnmpsa This lets you start and stop the NDS 
subagent. 

eDirectory LDAP support nldap This lets you load and unload the LDAP library 
that NetIQ eDirectory uses to provide LDAP 
support. It is not actually a service. 

FTP pure-ftpd This is used by the Novell FTP Pattern. 
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Services Associated with Scripts 


iPrint 


Script Name 
cups 
novell-idsd 


novell-ipsmd 


Notes 


These scripts are required by iPrint 


cups lets you to start and stop the cupsd 
daemon that provides spooling and printing 
functionality for local and remote printers and 
is always required, even if printers are 
broadcasted ("Browsing") into (sub)nets. 


novell-ipsmd lets you to start and stop the 
ipsmd daemon that manages printers that are 
assigned under a Print Manager. 


novell-idsd lets you to start and stop the 
idsd daemon that manages drivers that are 
assigned under a Driver Store. 


Kerberos KDC Service 


xad-krb5kdc 


Kerberos Password Change Server 


xad-kpasswdd 


Linux User Management 


namcd 


nscd 


These daemons are required by Linux User 
Management and work together to ensure 
good performance. 


The namcd daemon caches user and group 
names and IDs from eDirectory, speeding 
subsequent lookups of cached users and 
groups. 


The nscd daemon caches host names and 
addresses. 


Logging 


syslog 


This is used for logging by many OES 
services. 


Name Service Cache Daemon 


nsdc 


Novell AFP novell-afptcpd This script starts and stops the afptcpd 
daemon, which is the Novell AFP service 
daemon 

Novell AFP avahi-daemon This is used by AFPtcpd to advertise itself. 

Novell CIFS novell-cifs This script starts and stops the cifsd daemon, 
which is the Novell CIFS service daemon 

Novell DHCP dhcpd 

NetStorage (actually XTier) novell-xregd NetStorage runs inside the novell-xsrvd XTier 
Web Services daemon, and also utilizes 

novell-xsrvd 
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Tomcat services for certain other functions. 


novell-xregd is the init script for starting and 
stopping XTier's registry daemon. It is part of 
the novell-xtier-base RPM and is 
enabled by default for run levels 2, 3, and 5. 


novell-xsrvd is the init script for starting and 
stopping XTier's Web services daemon. It is 
also part of the novell-xtier-web RPM and 
is enabled for run levels 2, 3, and 5. 


Services Associated with Scripts Script Name Notes 


Novell Cluster Services (NCS) adminfs This is used for NCS through iManager and 
the command line interface. 


Novell Cluster Services (NCS) novell-ncs NCS uses some shell scripts and utilities that 
come with the heartbeat package. For 
example, NCS uses a binary called send arp 
to send out ARP packets when a secondary 
address is bound. 


NCS never runs the heartbeat daemons. In 
fact, NCS and heartbeat are mutually 
exclusive when it comes to execution, and 
heartbeat must always be configured to not 
run (chkconfig heartbeat off) when NCS is 
loaded on the server. 


Novell Identity Translator novell-nit This script runs by default on every OES 2015 
SP1 and later server with NSS volumes and 
provides user IDs (UIDs) for NSS file access. 


Use rcnovell-nit followed by start, stop, 
restart, or status to view or alter the run 
state as needed. 


Novell Remote Manager novell-httpstkd This script runs by default on every OES 
server and enables access to NRM for Linux 
through a browser. 


Use this script followed by the status option to 
view current status. Or use stop, start, or 
restart options to alter the run state of the 
NRM daemon as needed. 


Novell Storage Services novell-nss This script runs by default on every OES 
server with NSS volumes and enables access 
to the NSS runtime environment. 


To see if the NSS kernel modules and NSS 
admin volume are running, enter service 
novell-nss status, /etc/init.d/ 
novell-nss status,or rcnovell-nss 
status at a command prompt. If they are not 
running, use the start option to start them. 
You cannot stop NSS. 


Novell Remote Manager e-mail postfix Novell Remote Manager uses this to send 

notifications notifications as configured. 

NSS Auditing novell-vigil This is the NSS auditing daemon. 

NTP ntp This is the SLES 11 Network Time Protocol 
daemon. 

Patching novell-zmd This is the GUI patch updater daemon. 

RPC Daemon rpcd 

rsync daemon rsyncd DSfW depends on this 

Samba nmb This is the Samba NetBIOS naming daemon. 

Samba CIFS support smb This script runs the Samba daemon. 
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Services Associated with Scripts Script Name Notes 

Samba WINBIND daemon winbind 

SFCB CIMOM sfcbd This is used to start the SFCB CIMOM 
daemon, which is an integral part of the 
iManager plug-ins for LUM, Samba, NSS, 
SMS, and NCS. AFP, CIFS, iPrint, and NRM 
also use SFCB. 

Novell Remote Manager on OES gets its 
server health information from CIMOM. 

SLP support slpd This lets you start and stop OpenSLP, which is 
a key component for eDirectory and certain 
other services and clients. 

sshd service sshd DSfW depends on this 

Storage Management Services novell-smdrd This lets you start and stop the SMDR 


daemon precess. It also loads and unloads 
the NSS zapi kernel module used by SMS to 
back up the NSS volumes. 


Tomcat novell-tomcat6 This script sets up the Tomcat included with 
SLES 11 specifically for OES services, such 
as the Welcome pages. 

Zypper zypper This is the Zypper command line daemon. 
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System User and Group 
Management in OES 2015 SP1 


This section discusses the users and groups that are used by Open Enterprise Server. Administrative 
users are discussed in Appendix I, "Administrative Users and Groups in OES 2015 SP1,” on 
page 283. 

« Section H.1, "About System Users and Groups," on page 257 

« Section H.2, "Understanding Proxy Users," on page 259 

« Section H.3, "Common Proxy User," on page 264 

« Section H.4, "Planning Your Proxy Users," on page 268 

« Section H.5, "Implementing Your Proxy User Plan," on page 277 

* Section H.6, "Proxy Users and Domain Services for Windows," on page 278 

* Section H.7, "System Users," on page 278 

* Section H.8, "System Groups," on page 279 

* Section H.9, "Auditing System Users,” on page 280 


H.1 About System Users and Groups 


"Regular" network users rely on network services. System users and groups support those services. 


Some NetWare administrators are concerned about the number of system users and groups on an 
OES server. They wonder what functions system users perform, why there are "so many" of them, 
and how they impact licensing and network security. 


The answers to these and other questions are found in the sections that follow. 


¢ Section H.1.1, "Types of OES System Users and Groups,” on page 257 
¢ Section H.1.2, “OES System Users and Groups by Name,” on page 258 


H.1.1 Types of OES System Users and Groups 


The users and groups that support OES services can be grouped into the three types shown in Table 
H-1. 


System User and Group Management in OES 2015 SP1 257 


Table H-1 Types of System Users and Groups with Examples 


System User or Group Type Purpose Examples 


Proxy User Perform very specific service- * cifsProxyUser-servername 


related functions, such as 
* LUM Proxy user 


* Retrieving passwords and 
service attributes 


* Writing Service information in 
eDirectory. 


* Providing a user ID (uid) that 
the associated service 
daemon uses to run. 


System Group * Facilitate the management of * DHCP 
system users * DNSDHCP 
* Provide access rights to 
service data on the server or 
in the eDirectory tree. 
System User The daemons associated with the + wwwrun 
respective services run as these nous 
* iprint 
users. 


H.1.2 OES System Users and Groups by Name 


Table H-2 lists the users and groups that OES services depend on and use. 


Table H-2 System User and Groups Listing 


System User or Group Object Type Associated Service 
AfpProxyUser-servername Proxy User AFP 
CifsProxyUser-servername Proxy User CIFS 
cluster name MGT GRP-context System Group NCS 
DHCP LDAP Proxy Proxy User DHCP 
dhcpd System User DHCP 
DHCPGroup System Group DHCP 
DNS Proxy Proxy User DNS 
DNSDHCP-GROUP System Group DNS 
iFolderProxy Proxy User iFolder 3 
iprint System User iPrint 
Iprint (POSIX) System Group iPrint 


iprintgrp (eDirectory) 
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H.2 


H.2.1 


System User or Group Object Type Associated Service 
LUM proxy Proxy User Linux User Management 
(optional) 

named System User DNS 

NetStorage Proxy Proxy User NetStorage 

novell nobody System User CIMOM 

novell nogroup System Group CIMOM 

novixregd System User XTier 

novixsrvd System User XTier 

novixtier System Group XTier 


OESCommonProxy hostname 


System User 


AFP, CIFS, DNS, DHCP, iFolder, 
NetStorage, Clustering (NCS), Linux 
User Management (optional) 


server name-SambaProxy 


Proxy User 


Samba (Novell) 


server name-W-SambaUserGroup 


System Group 


Samba (Novell) 


server nameadmin Proxy User NSS 

WWW System Group Apache 
Tomcat 

wwwrun System User Apache 


Understanding Proxy Users 


The subject of OES proxy users is somewhat complex. Therefore, it’s a good idea to understand the 
basics before planning your implementation strategy. 


IMPORTANT: The information in the following sections only answers security questions and provides 
general information. It is not intended to be used for the manual configuration of proxy users. 


¢ Section H.2.1, "What Are Proxy Users?,” on page 259 

¢ Section H.2.2, "Why Are Proxy Users Needed on OES?,” on page 260 

¢ Section H.2.3, "Which Services Require Proxy Users and Why?,” on page 260 
¢ Section H.2.4, "What Rights Do Proxy Users Have?,” on page 261 


What Are Proxy Users? 


As the name implies, proxy users are user objects that perform functions on behalf of OES services. 


Proxy user accounts do not represent people, rather they are eDirectory objects that provide very 
specific and limited functionality to OES services. Generally, this includes only retrieving service- 
related information, such as user passwords and service attributes, but sometimes proxy users also 
write service information in eDirectory. 
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H.2.2 


H.2.3 


Many but not all OES services rely on proxy users to run on Linux (see "Which Services Require 
Proxy Users and Why?" on page 260). Proxy user creation and/or configuration is therefore an 
integral part of configuring OES. 


None of the OES services require that you specify proxy user information during the OES installation, 
but some, such as AFP, DNS/DHCP, CIFS, and iFolder, give you the option to do so. Others, such as 
NCS and NSS create proxy users without user input. 


Why Are Proxy Users Needed on OES? 


OES provides the Novell services that were previously only available on NetWare. 


To make its services available on Linux, Novell had to accommodate a fundamental difference 
between the way services run on NetWare and the way they run on Linux. 


* NetWare Services: The NetWare operating system and eDirectory are tightly integrated. This 
allows the services (NLMs) on NetWare to assume the identity of a server object in eDirectory, 
thus gaining access to the other objects and information in eDirectory that are needed for the 
services to run. 


* OES Services: eDirectory also runs very well on OES, and it provides the infrastructure on 
which OES services rely, but it is not integrated with the Linux operating system. 


On Linux servers there is no concept of a service, such as Apache or iFolder running as a server 
object. Instead, each service runs using a User ID (uid) and a Group ID (gid) that the Linux 
server recognizes as being valid. 


Which Services Require Proxy Users and Why? 
The following services utilize a proxy user. 


Table H-3 Proxy Users Functions Listed by Service 


Associated Service Example Proxy User Name Services That the User Provides 
AFP OESCommonProxy hostname Retrieves AFP user information. 
Or 


AfpProxyUser-servername 


CIFS OESCommonProxy hostname Retrieves CIFS user information. 
Or 


CifsProxyUser-servername 


Clustering (NCS) OESCommonProxy hostname The clustering administrator and the proxy 
user can be two separate users. For more 
Or information, see "DES Common Proxy User 


" in the OES 2015 SP1: Novell Cluster 


installing admin user : : E j : 
g Services for Linux Administration Guide. 


DHCP OESCommonProxy_hostname Lets the service access DHCP objects in 


eDirectory. 
Or 


DHCP_LDAP_Proxy 
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Associated Service Example Proxy User Name Services That the User Provides 


DNS OESCommonProxy hostname Lets the service access DNS objects in 
eDirectory. 
Or 
DNS Proxy 
iFolder 3 OESCommonProxy hostname Connects to the eDirectory server and 
ö retrieves the following information: 
r 
* modifytimestam 
iFolderProxy y E 
* cn 
IMPORTANT: The Common Proxy f 
user cannot be used if iFolder is * mail 
running on a cluster node. * sn 
* GUID 


* givenName 


* member 
Linux User Management OESCommonProxy hostname Searches the tree for LUM users. 
Or 
LUM proxy 
NetStorage OESCommonProxy hostname Performs LDAP searches for users logging 
ör into NetStorage. 


NetStorage Proxy 


NSS server nameadmin Reads user objects and maintains the 
volume, pool, and other storage system 
objects. 


This user performs some of the same 
functions as proxy users do for other 
services. However, unlike other OES 
services that can share proxy users, NSS 
requires a unique proxy user for each server. 


Samba (Novell) server name-SambaProxy Searches the LDAP tree (eDirectory) for 
Samba users. 


H.2.4 What Rights Do Proxy Users Have? 


Each OES service's YaST installation automatically adds the required rights to the proxy user 
specified for the service. 


Unless otherwise specified, each of the following users has the standard set of user rights in 
eDirectory: 


* Self: 
Login Script: 
Read Write, Not inheritable 


Print Job Configuration: 
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Read Write, Not inheritable 


[All Attribute Rights]: 


Read, Inheritable 


* [Public] 


Message Server: 


Read, Not inheritable 


* [Root] 


Group Membership 


Read, Not inheritable 


Network Address 


Read, Not inheritable 


In addition, each proxy user is granted additional rights as summarized in Table H-4. 


Table H-4 Proxy Users Rights 


Associated Service 


AfpProxyUser-servername 


Example Proxy User Name Default Rights Granted 


* 


This proxy user has Compare and Read 


AFP 


CIFS 


Clustering (NCS) 


CifsProxyUser-servername 


OESCommonProxy hostname 
Or 


installing admin user 


rights to the specified AFP user search 
context. 


This proxy user has Compare and Read 
rights to the specified CIFS user search 
context. 


The proxy user has rights (granted through 
membership in the NCS Management 
group) to communicate with eDirectory on 
behalf of the clustering service. 


DHCP DHCP LDAP Proxy * No rights are assigned directly, but 
membership in the DHCPGroup, which 
does have assigned rights, provides the 
rights it needs. 

DNS DNS Proxy + No rights are assigned directly, but 


membership in the DNS-DHCPGroup, 
which does have assigned rights, provides 


the rights it needs. 
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Associated Service Example Proxy User Name 


iFolder 3 iFolderProxy 


Default Rights Granted 


* Additional eDirectory rights include: 


[Entry Rights] 
Browse 
LDAP ACL representation: 
1#subtree#iFolderProxy# 
[All Attributes Rights] 
Read, Compare 
LDAP ACL representation: 


3#subtree#iFolderProxy# 


Linux User LUM proxy 
Management 


If created, this proxy user has Search 
rights on Unix Config & Unix Workstation 
Objects. 


NetStorage NetStorage Proxy 


Additional eDirectory rights: 
[Entry Rights] 
Browse 
LDAP ACL representation: 
1#subtree#NetStorage_Proxy# 
[All Attributes Rights] 
Read, Compare 
LDAP ACL representation: 


3#subtree#NetStorage_Proxy# 


NSS server_nameadmin 


Additional eDirectory rights: 


Supervisor right to the container it was 
created in. 


Samba (Novell) server_name-SambaProxy 


The Universal Password policy associated 
with the Samba users grants this proxy 
user the right to retrieve user passwords. 


Additional eDirectory rights: 

Rights to itself — Supervisor attribute right 
Rights to the OU where it is located 

All Attribute rights — Read Write 

Entry rights — Browse Create 


samba* — Create Read Write 
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H.3 Common Proxy User 


* 


* 


Section H.3.1, “Common Proxy User FAQ,” on page 264 
Section H.3.2, "Managing Common Proxy Users," on page 266 


H.3.1 Common Proxy User FAQ 


* 


* 


* 


* 


* 


“Why Would | Want to Specify Common Proxy Users?" on page 264 

"Why Was a Proxy User Added to Novell Cluster Services?" on page 264 

"Which Services Can and Cannot Leverage the Common Proxy User?" on page 265 
"Can a Common Proxy User Service Multiple Servers?" on page 265 

"Can | Change the Common Proxy User Name and Context?" on page 266 

"Can | Assign the Common Proxy User After Services Are Installed?" on page 266 
“What About Upgraded Servers Using a Common Proxy?" on page 266 


"Are There Important Limitations to Keep in Mind?" on page 266 


Why Would I Want to Specify Common Proxy Users? 


The implementation of a common proxy user in OES 2015 SP1 addresses the following 
administrative needs: 


* 


Limit the Number of Proxy Users: By default, the number of proxy users in an eDirectory tree 
can quickly become quite large. And even though proxy users don't consume user license 
connections, many administrators are disconcerted by the sheer number of objects to manage 
and track. 


Common proxy users reduce the default number of proxy users from one per service to basically 
one per OES 2015 SP1 server. 


Accommodate Password Security Policies: Many organizations have security policies that 
require periodic password changes. Some administrators are overwhelmed by having to 
manually track all proxy users, change their passwords, and restart the affected services after 
every change. 


Common proxy users have their passwords automatically generated by default and changed at 
whatever interval is required. Services are restarted as needed with no manual intervention 
required. 


Prevent Password Expiration: When proxy user passwords expire, OES 2015 SP1 services 
are interrupted, leading to network user frustration and administrator headaches. 


Automatic password management for common proxy users ensures that services are never 
disrupted because of an expired password. 


Why Was a Proxy User Added to Novell Cluster Services? 


In OES 2 SP3 and later, the eDirectory communication functionality that was previously performed by 
the designated NCS administrator, has been separated out so that it can now be performed by a 
system user if so desired. 


This aligns NCS functionality with other OES services that use proxy (system) users for similar 
functions. For more information, see “OES Common Proxy User " in the OES 2015 SP1: Novell 
Cluster Services for Linux Administration Guide. 
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Which Services Can and Cannot Leverage the Common Proxy User? 


* "Services That Can Leverage the Common Proxy User" on page 265 
* "Services That Cannot Leverage the Common Proxy User” on page 265 


Services That Can Leverage the Common Proxy User 


The following OES services are automatically configured at install time by default to use your 
Common Proxy User (if specified): 

* Novell AFP 

* Novell CIFS 

* Novell Cluster Services 

* Novell DNS 

* Novell DHCP 

* Novell iFolder 


* Novell NetStorage 


The following OES service can be configured at install time to use your Common Proxy User (if 
specified): 


* Linux User Management (having a proxy user is optional) 


Services That Cannot Leverage the Common Proxy User 

The following services that use proxy users do not leverage the Common Proxy user for the reasons 
listed: 

Service Reason 

Novell Samba Samba proxy password requirements are not a good fit with the Common 


Proxy user. The user's credentials are written in the CASA/password files 
or databases. 


Novell Storage Services This requires full rights to administer NSS and continues to require a 
system-named user with a system-generated password. 


Can a Common Proxy User Service Multiple Servers? 
No. 


The common proxy user is designed and configured to be the common proxy for the OES services on 
a single server. Each subsequent new server needs a separate and distinct common proxy created 
for its services. 


System User and Group Management in OES 2015 SP1 265 


Can I Change the Common Proxy User Name and Context? 


The Common Proxy User Name cannot be changed at install time and should not be manually 
changed later. Best practices dictate that each proxy user name reflect the name of the server it is 
associated with. 


The context can be changed at install time. However, eDirectory best practices suggest that object 
locations within the tree reflect the object purpose and scope of influence or function. For this reason, 
the OES install proposes the same context that you specify for the server, for its associated common 
proxy as well. 


Can I Assign the Common Proxy User After Services Are Installed? 


Yes. See “Assigning the Common Proxy to Existing Services” on page 267. 


What About Upgraded Servers Using a Common Proxy? 


You can change the services running on an upgraded OES 2015 SP1 server to leverage a Common 
Proxy user. See “Assigning the Common Proxy to Existing Services” on page 267. 


Are There Important Limitations to Keep in Mind? 


Yes. 


iFolder must not be configured to use a Common Proxy on a cluster node. 


H.3.2 Managing Common Proxy Users 


Common proxy users are eDirectory objects and can therefore be managed via iManager. However, 
after the initial setup is complete, there should generally be no reason for OES administrators to 
directly manage Common Proxy users. 


Use the information in the following sections to understand and implement common proxy user 
management. 


+ "Always Use LDAP Port 636 to Communicate with eDirectory” on page 266 
* "Assigning the Common Proxy to Existing Services" on page 267 


+ “Changing Proxy Passwords Automatically" on page 267 


Always Use LDAP Port 636 to Communicate with eDirectory 
The Common Proxy user management scripts communicate with eDirectory using port 636 only. See 


the instructions in “Installing OES 2015 SP1 as a New Installation" in the OES 2015 SP1: Installation 
Guide). 
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Assigning the Common Proxy to Existing Services 


You can assign the common proxy user to any of the services listed in "Services That Can Leverage 
the Common Proxy User” on page 265 using the move to common proxy.sh script on your OES 
2015 SP1 server. In fact, if you have upgraded from SP2 and the server doesn't have a common 
proxy user associated with it, simply running the script will create and configure the proxy user and 
assign the services you specify. 
1 In the /opt/novell/proxymgmt/bin folder, run the following command: 
./move to common proxy.sh servicei,service2 
where the service entries are OES service names: novell-cifs, novell-dns, novell-dhcp, 
novell-iFolder, novell-netstorage, novell-lum, and/or novell-nc. 
Example scenario: 
* You have upgraded server myserver, which is located in o=novell and uses IP address 
10.10.10.1, from OES 2 SP3 to OES 2015 SP1. 
* The secure LDAP port for the server is 636. 
* Your eDirectory Admin user FQDN is cn=admin,o=novell. 
* Your Admin password is 123abc. 


* You want to create a common proxy user and assign it as the common proxy for the Novell DNS 
and DHCP services running on the server. 


* Therefore, you enter the following commands: 
cd /opt/novell/proxymgmt/bin 
./move to common proxy.sh -d cn-admin,o-novell -w 123abc -i 10.10.10.1 -p 636 - 
s novell-dhcp, novell-dns 


User cn=OESCommonProxy_myserver,o=novell is created with a system-generated password and 
assigned the Common Proxy Policy password policy. The DNS and DHCP services are configured to 
be serviced by the Common Proxy user. 


Changing Proxy Passwords Automatically 


You can configure your server so that your proxy users are regularly assigned new system-generated 
passwords by doing the following: 
1 Open the file /etc/opt/novell/proxymgmt/proxy users.conf in a text editor. 


2 List the FQDN of each proxy user on the server that you want to automatic password 
management set up for. 


For example you might insert the following entries: 


cn=OESCommonProxyUser_myserver,o=novell 
cn=myproxy,o=novell 


IMPORTANT: Users listed here must not be listed in the proxy_users.conf file on any other 
servers in the tree. 


3 Save the file. 
4 Enter the following commands: 


cd /opt/novell/proxymgmt/bin 
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H.4 


H.4.1 


change_proxy_pwd.sh -A Yes 
By default, the crontab job will run every 30 days. 


Planning Your Proxy Users 


Because of the prominent role played by the proxy users on your OES network, it is important that 
you understand your implementation options and the implications for each option. You can then plan 
an overall proxy user implementation strategy. 


¢ Section H.4.1, “About Proxy User Creation,” on page 268 
¢ Section H.4.2, “There Are No Proxy User Impacts on User Connection Licenses,” on page 272 
¢ Section H.4.3, “Limiting the Number of Proxy Users in Your Tree,” on page 272 


¢ Section H.4.4, “Password Management and Proxy Users,” on page 274 


About Proxy User Creation 


The first step in planning your proxy user implementation strategy is understanding the do’s and 
don'ts of proxy user creation. 


* "Creation Options" on page 268 
+ "Do Not Manually Configure Proxy Users" on page 271 
* "Avoid Assigning an Admin User As a Proxy User" on page 272 


Creation Options 


Table H-2 presents information about the creation options for each OES proxy user. 


Table H-5 Proxy User Creation Options 


Associated Service Proxy User Name Creation Information 

Service if Applicable 

AFP OESCommonProxy hostna * Common Proxy User: If a Common Proxy User is 
me specified, AFP will be automatically configured to use 


o it by default, but you have the option to change this. 
r 


+ No Common Proxy User: If a Common Proxy User 
AfpProxyUser-servername is not specified, the AFP YaST install automatically 
does the following: 


* Creates a proxy user named AfpProxyUser- 
servername in the same context as the server. 


* Generates a password, and stores it in CASA. 


Alternatively, you can modify any of the defaults, 
including the password. Or if you have already created 
a proxy user, you can specify that as well. 
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Associated 
Service 


CIFS 


Service Proxy User Name 
if Applicable 


OESCommonProxy hostna 
me 


Or 


CifsProxyUser-servername 


Creation Information 


Common Proxy User: If a Common Proxy User is 
specified, CIFS will be automatically configured to use 
it by default, but you have the option to change this. 


No Common Proxy User: If a Common Proxy User 
is not specified, the CIFS YaST install automatically 
does the following: 


* Creates a proxy user named cifsProxyUser- 
servername in the same context as the server. 


* Generates a password, and stores it in either 
CASA or in an encrypted file on the server, 
depending on which option you select. 


Alternatively, you can modify any of the defaults, 
including the password. Or if you have already created 
a proxy user, you can specify that as well. 


Clustering (NCS) 


OESCommonProxy hostna 
me 


Or 


installing admin user 


Common Proxy User: If the Common Proxy User is 
specified, it is granted membership in the 

NCS Management group, which enables it to 
communicate with eDirectory on behalf of the 
clustering service. 


No Common Proxy User: If a Common Proxy User 
is not specified, the system automatically uses the 
installing administrator, which is granted membership 
in the NCS Management group, which enables it to 
communicate with eDirectory on behalf of the 
clustering service. 


DHCP OESCommonProxy hostna Common Proxy User: If a Common Proxy User is 
me specified, DHCP will be automatically configured to 
use it by default, but you have the option to change 
Or : 
this. 
installing administrator No Common Proxy User: If a Common Proxy User 
is not specified, the admin account that installs the 
server is assigned as the DHCP proxy user. 
If you want to assign an alternate user account, it must 
already exist in the tree and be able to access the 
DHCP server object. 
DNS OESCommonProxy hostna Common Proxy User: If a Common Proxy User is 


me 
Or 


installing administrator 
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specified, DNS will be automatically configured to use 
it by default, but you have the option to change this. 


No Common Proxy User: If a Common Proxy User 
is not specified, the admin account that installs the 
server is assigned as the DNS proxy user. 


If you want to assign an alternate user account, it must 
already exist in the tree and have Read, Write, and 
Browse rights in the contexts where the DNS Locator, 
Root Server, and Group Object are created. 
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Associated 
Service 


Domain Services 


Service Proxy User Name Creation Information 


if Applicable 


OESCommonProxy hostna * 


Common Proxy User: If a Common Proxy User is 


for Windows me specified, DSfW will be automatically configured to 
(DSfW) use it by default, but you have the option to change 
or this. 

DNS + No Common Proxy User: If a Common Proxy User 
is not specified, the admin account that installs the 
server is assigned as the DNS proxy user. 
Alternatively, you can modify any of the defaults, 
including the password, or if you have already created 
a proxy user, you can specify that as well. The user 
must have the Read right to the LDAP service. 

iFolder 3 OESCommonProxy_hostna + Common Proxy User: If a Common Proxy User is 
me specified, iFolder will be automatically configured to 
use it by default, but you have the option to change 

a this. 

iFolderProxy * No Common Proxy User: If a Common Proxy User 
is not specified, the system automatically creates a 

IMPORTANT: The proxy user named iFolderProxy. 

Common Proxy user cannot 

be used if iFolder is running Alternatively, you can modify any of the defaults, 

on a cluster node. including the password, or if you have already created 
a proxy user, you can specify that as well. The user 
must have the Read right to the LDAP service. 

Linux User OESCommonProxy hostna By default, no LUM proxy user is created. 
Management me 

* Common Proxy User: If a Common Proxy User is 

Or specified, you have the option of specifying that it be 

; used as the LUM proxy user. If you do this, LUM is 

LUM_proxy (optional) automatically configured to use it. 

* No Common Proxy User: If you create a proxy user 
for LUM, it will be assigned rights to search the LDAP 
tree for LUM objects. 

If you assign a previously created user as the LUM 
proxy user, it must have the Read right to the LDAP 
service. 

NetStorage OESCommonProxy hostna * Common Proxy User: If the Common Proxy User is 
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me 
Or 


Installing administrator 


specified, NetStorage will be configured to use it by 
default, but you have the option to change this. 


You must manually configure the proxy user with the 
rights specified in NetStorage in Table H-4 on 

page 262. For more information, see "Changing the 
NetStorage Default Configuration " in the OES 2015 
SP1: NetStorage Administration Guide for Linux. 


No Common Proxy User: If a Common Proxy User 
is not specified, the system automatically uses the 
installing administrator. 


Alternatively, you can modify any of the defaults, including 
the password, or if you have already created a different 
proxy user, you can specify that as well. The user must 
have the Read right to the LDAP service. 


Associated Service Proxy User Name Creation Information 


Service if Applicable 

NSS server nameadmin This admin account must have full rights to administer NSS 
and must be unique to each server. The Common Proxy 
User does not apply to NSS. 

Samba (Novell) server name-SambaProxy By default, the Samba proxy user is created in the container 


specified as the Base Context for Samba Users and is 
named servername-sambaProxyUser. 


A password is automatically generated for the default proxy 
user, or you specify a different password for this user when 
you configure Novell Samba. 


You can specify another eDirectory user as the Samba 
proxy user. If you do, be aware of the following: 


+ |f you specify a user that doesn't already exist in 
eDirectory, the user account is created and granted 
the necessary rights. You must also specify a 
password for the new user. 


* |f you specify an existing eDirectory user, it is 
assumed that you have already created the user 
account with the necessary rights and no 
modifications are made to the existing user. 


+ |f you specify an existing eDirectory user but enter a 
new password, you are prompted to change the 
password for that user. 


Because of the Samba proxy password requirements, the 
Common Proxy User cannot be used with Novell Samba. 


Do Not Manually Configure Proxy Users 


Best practices for most OES installation scenarios dictate that either the Common Proxy user be used 
or that proxy users be created in eDirectory prior to installing OES. For more information, see 
"Common Proxy User" on page 264 and "Limiting the Number of Proxy Users in Your Tree" on 

page 272. 


IMPORTANT: The information in the preceding and following sections only answers security 
questions and provides general information. It is not intended to be used for the manual configuration 
of proxy users. 


Manually created proxy users must be configured for OES-rootservice use only by the YaST based 
install, not manually. 
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Avoid Assigning an Admin User As a Proxy User 


We recommend that you always use the special-purpose proxy user accounts described in this and 
the accompanying sections rather than specifying admin users as proxy users. Best practice dictates 
that proxy users have strictly limited functionality that supports only their specific system-level 
responsibilities. Proxy users should not be used for any other purposes. 


Although specifying an admin user as the proxy user appears to be an easy way of setting up OES 
services (and is the install default in some cases if the Common Proxy user option isn't selected), 
there are potential problems. Mixing actual users with system-level functionality always creates some 
risk. 


The following is a real-life example of risks that can occur when admin users are assigned as proxy 
users: 


Novell Support received a call from an administrator who was getting locked out due to intruder 
detection after changing the administrator password. The lockout happened several times each day 
and seemed to be coming from the OES servers. The support technician checked LUM and all of the 
services he could think of, and didn't see the admin credentials anywhere. 


Further investigation revealed that the administrator credentials had been used as the proxy user 
credentials for some of the OES service installations. Consequently, the credentials were stored in 
CASA for use when the OES services came up. 


Because the Admin password had changed, the CASA credentials had expired and service 
authentication requests were failing, resulting in the intruder detection lockout. 


H.4.2 There Are No Proxy User Impacts on User Connection 
Licenses 


Novell policy dictates that proxy users that function only as proxy users, are simply system users. 
Therefore, proxy users do not consume user connection licenses. 


H.4.3 Limiting the Number of Proxy Users in Your Tree 


The main purposes of the common proxy users are to reduce the number of proxy users in a tree and 
simplify proxy user management. Therefore, the common proxy user is the default in all applicable 
scenarios. 


Table H-6 outlines various alternative options for limiting the number of proxy users in your tree and 
summarizes the security and manageability considerations of each approach. 
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Table H-6 Options for Limiting the Number of Proxy Users 


Approach 


Per Service per 
Server 


Security Considerations 


For CIFS, iFolder 3, and 
Samba this is the most secure 
option. By default, the 
passwords for these are 
system-generated and not 
known by anyone. 


For LUM there is no option to 
have a system-generated 
password. 


For DNS, DHCP, and 
NetStorage, the install admin's 
credentials are used by 
default. This has separate 
security implications as 
outlined in "Avoid Assigning 
an Admin User As a Proxy 
User" on page 272. 


Manageability Considerations 
This approach requires no proxy user planning. 
Services are installed at the same time as the OES server. 


This is a good option for small organizations or installations 
where only a few services are used. 


This is not a good option if security policies dictate that all 
passwords must be reset periodically. 


Per Server 


Per Partition 


This confines any security 
vulnerabilities to individual 
servers and is the scenario for 
which the Common Proxy 
User was developed. 


This confines any security 
vulnerabilities to individual 
partitions. 


This requires that a proxy user for the server is created 
before the server is installed. 


If the Common Proxy User is not leveraged, then for the 
first server in the tree, eDirectory and iManager must be 
installed with the server. After the server installation 
finishes, a proxy user can be created. And finally the 
services can be installed and configured to use the proxy 
user for the server. 


This approach is useful when each OES server is managed 
by a separate administrator, or for enterprises where 
branch users access a server in the branch office. 


Knowing the proxy user password is not required unless 
additional services will be installed or password policies 
require periodic changing, in which cases the install admin 
must know the proxy user's password. 


This is useful when users are co-located with the OES 
servers in a single partition, and cross-partition access of 
Users to services is rare. 


This is a good approach for organizations where eDirectory 
administration is done at a partition level. 


This requires that a proxy user for the first server in the 
partition is created before services are installed in the 
partition. 


The install admin must know the proxy user's password. 
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Approach Security Considerations Manageability Considerations 


Per Service This confines any security For example, you might have one proxy user for CIFS, one 
vulnerabilities to individual for DNS/DHCP, one for iFolder, one for iPrint etc. 
services. 


This is useful in trees where the users and servers are not 
It also ensures that proxy user co-located, and different services are administered by 
rights are not overloaded but different administrators. 


are distributed so that there is . . oo 
a single proxy user for each This requires that a proxy user for the service is created 


type of service before the service is installed in the tree. 


The install admin must know the proxy user’s password. 


Per Tree This exposes all OES services A proxy user for the tree must be created before any OES 
and servers in the tree to any services are installed in the tree. 


security vulnerabilities. dm : " 
This is suitable for organizations that have 


* Centralized eDirectory administration 


* Users that are not confined to the partition or subtree 
where the OES servers reside, but instead access 
different OES servers from all over the tree. 


The install admin must know the proxy user's password. 


H.4.4 Password Management and Proxy Users 


Proxy user passwords must be stored on the individual OES servers where the services are installed 
because proxy users must be able to log in to eDirectory to perform their required functions. 

+ "Auto-Generated vs. Manually Specified Passwords" on page 274 

* “Passwords Are Stored on the Server" on page 274 

* "Avoid Password Expiration Problems" on page 275 

+ "Changing Proxy Passwords Automatically" on page 276 


+ "Changing Proxy Passwords Manually” on page 276 


Auto-Generated vs. Manually Specified Passwords 


* Auto-Generated Passwords: These offer the highest security because the passwords are 
known only to the system. 


The Common Proxy User, CIFS Proxy User, iFolder Proxy User (YaST calls this the LDAP proxy 
user), and Samba Proxy User all use auto-generated passwords by default. 


* Manually Specified Passwords: Although you can change the auto-generated passwords for 
the various proxy users, this is not recommended because it is less secure and requires that 
someone keep track of the passwords. Also, manually specified passwords can easily lead to 
problems, such as service disruption. For a related example of the problems this can cause, see 
"Avoid Assigning an Admin User As a Proxy User" on page 272. 


Passwords Are Stored on the Server 


Of course all proxy user passwords are stored in eDirectory. Table H-7 explains where they are stored 
on the server and how they can be reset if needed. 
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Table H-7 Password Storage Locations 


Associated 
Service 


AFP 


Where the Password Is Stored Locally 


If the service-specific proxy user is used, 
the password is stored in either CASA or 
in an encrypted file, depending on the 
configuration option specified during 
service installation. 


How the Password Can Be Reset 


You can reset the password using iManager 
or the CASAcli tool. 


CIFS 


If the service-specific proxy user is used, 
the password is stored in either CASA or 
in an encrypted file, depending on the 
configuration option specified during 
service installation. 


You can use iManager to reset the password 
in CASA or in the encrypted file, or the 
CASAcli tool if it is stored in CASA. 


Common Proxy 
User 


This password is stored in CASA. 


We recommend that you only use the 
change proxy pwd.sh script to manage 
Common Proxy User passwords. 


DHCP The service-specific password is stored in You can set the password using the CASAcli 
CASA. tool. 
DNS If the service-specific proxy user is used, 
the service-specific password is stored in 
CASA if it is available. If CASA is not 
available, it is stored in an encrypted file. 
iFolder 3 If the service-specific proxy user is used, It can be changed either from a terminal 
the service-specific password is stored in prompt using the iFolder command line 
the iFolder store with PKI cryptography. ^ utilities or through the iFolder Admin Console. 
Linux User If the service-specific proxy user is used, This can be changed in iManager through the 
Management the service-specific is stored in CASA. Linux User Management plug-in. 
NetStorage If the service-specific proxy user is used, This can be changed in iManager through the 
the service-specific password is stored in  NetStorage plug-in. 
the XTier registry. 
NSS This password is system-generated at install 


time and cannot be reset. 


Samba (Novell) 


The service-specific password is stored in 
Samba. 


You can change the password by using the 
smbpasswd command. 


IMPORTANT: Although the YaST based install can sometimes be used successfully to reconfigure 
some OES services, Novell neither recommends nor supports that practice. 


Avoid Password Expiration Problems 


Many organizations require that all network users have password policies to enforce regular 
password expiration and change. 


Such policies create complications for the proxy user design. Proxy user passwords are stored on the 
local system to enable the OES services to log in to eDirectory. Every time a password change is 
forced in eDirectory, services stop working until the password is synchronized on the server. 
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These problems can be avoided by: 


* Notassigning proxy users a password policy that enforces password expiration. 
* Not using real user credentials for proxy users. See "Avoid Assigning an Admin User As a Proxy 
User" on page 272. 


If password expiration policies cannot be avoided, or a security policy dictates that proxy user 
passwords must be changed periodically, we strongly urge you to implement an automatic password 
change routine as explained in"Changing Proxy Passwords Automatically" on page 276. 


Otherwise you should probably do the following. 
* Ensure that the responsible administrator knows or has a record of each proxy user's password 
and is aware of when each password expires. 


* Before passwords expire, change them in eDirectory and reset them on the server. See the 
information in Table H-7. 


Changing Proxy Passwords Automatically 


You can configure your server so that your proxy users are regularly assigned new system-generated 
passwords by doing the following: 
1 Open the file /etc/opt/novell/proxymgmt/proxy users.conf in a text editor. 


2 List the FQDN of each proxy user on the server that you want to automatic password 
management set up for. 


For example you might insert the following entries: 


cn=OESCommonProxyUser_myserver.o=novell 
cn=myproxy.o=novell 


IMPORTANT: Users listed here must not be listed in the proxy_users.conf file on any other 
servers in the tree. 
3 Save the file. 
4 Enter the following commands: 
cd /opt/novell/proxymgmt/bin 
change_proxy_pwd.sh -A Yes 
By default, the crontab job will run on the fifteenth (15th) day of each month. 


Changing Proxy Passwords Manually 


The change_proxy_pwd.sh command can also be used to enter a proxy user password. 


IMPORTANT: If you enter a password by using the change_proxy_pwd.sh command, the password 
cannot contain special shell variables ($#, $_, or #?). These characters are interpreted by the shell 
while processing service scripts. 


The workaround is to enter the password within single quotes. For example, you can enter the 
password novell$$ as 'novell$$'. The shell doesn't interpret content within single quotes. 
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H.5 


H.5.1 


H.5.2 


Implementing Your Proxy User Plan 


The proxy users in OES can be configured at different levels within eDirectory, depending on your 
needs. 


IMPORTANT: If you plan to use the Common Proxy User, you can ignore this note. 


The brief instructions that follow assume that you are installing into an existing tree and not 
leveraging the Common Proxy User. 


For new trees, you will need to install and configure eDirectory on the first server without configuring 
any other OES services. 


After the server is installed and you have created the required proxy users and passwords, then you 
can install the OES services and configure them to use the proxy users you have created. 


The exception to this is installing all services without changing the default configuration settings (see 
Table H-5 on page 268). In most cases a default configuration assigns the install admin as the proxy 
user for the service. 


¢ Section H.5.1, “Tree-Wide Proxy Users,” on page 277 

¢ Section H.5.2, "Service-Specific Proxy Users,” on page 277 
¢ Section H.5.3, “Partition-Wide Proxy Users," on page 278 

¢ Section H.5.4, "Server-Wide Proxy User,” on page 278 


¢ Section H.5.5, "Individual Proxy User Per-Server-Per-Service,” on page 278 


Tree-Wide Proxy Users 


Do the following: 


1. Create a proxy user in the eDirectory tree where the OES servers will be installed, and set the 
password. 


Consider naming the user to reflect its purpose. For example, name the proxy user 
Oes service proxy user. 


2. Use this proxy user and password while configuring the services on all of the OES servers in that 
tree. 


Service-Specific Proxy Users 


Do the following: 
1. Create a proxy user in the eDirectory tree for each type of OES service and set the passwords. 


Consider naming the user to reflect its purpose. For example, name the CIFS proxy user, 
cifs proxy user. 


2. Use these proxy users and passwords appropriately for each of the OES services on all OES 
servers. 
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H.5.3 Partition-Wide Proxy Users 


Do the following: 
1. Create one proxy user object per eDirectory partition in the OES tree, and set the password. 


Consider naming the user to reflect its purpose. For example, name the proxy user for the 
London regional office, london office proxy user. 


2. Use this proxy user and password for configuring all of the OES services on all the OES servers 
in that partition. 


H.5.4 Server-Wide Proxy User 


NOTE: The Common Proxy User is specifically designed as the default for this scenario. 


Do the following: 


1. Create one proxy user object per OES server (preferably in the same container as the server) 
and set the password. 


2. Use this proxy user and password as the proxy user for all the services on that particular OES 
server. 


H.5.5 Individual Proxy User Per-Server-Per-Service 


This is the installation default if the Common Proxy User is not utilized as explained in Table H-6, 
"Options for Limiting the Number of Proxy Users," on page 273. 


H.6 Proxy Users and Domain Services for Windows 


Proxy users are not used in DSfW. 


The Services part of the Trusted Computed Base has the rights to read users' supplemental 
credentials for authentication. A separate Kerberos process reads user passwords and performs the 
authentication. Another event handler in eDirectory creates the supplemental credentials for the user 
whenever the password is changed for that user. 


However, the DNS Proxy User is closely associated with DSfW and can leverage the Common Proxy 
User. 


H.7 System Users 


SLES and OES create system users on the local Linux system to provide user IDs (uids) to service 
processes. These users have rights to local files, such as configuration files. 


The services that rely on system users do not have passwords because they don't need to log in. 
They simply use their associated user IDs. 


When NSS is installed, some of these users are moved to eDirectory and LUM enabled. This is done 
to provide access to NSS data, to keep the user IDs the same across multiple servers, and to 
facilitate clustering and shared volumes. 


Table H-2 lists the various system users that are used by OES services. 


278 System User and Group Management in OES 2015 SP1 


Table H-8 System User Purposes 


System User Associated Service Purpose 
or Group 
Name 


dhcpd DHCP DHCP accesses local resources through this or an alternatively 
specified user. 


If the DHCP lease and configuration files are stored on NSS, the user 
must be moved to eDirectory and LUM enabled. 


dhcpd is used by default, but any local user can be used. 


iprint iPrint The iPrint daemons run as this user. 


If iPrint is moved to NSS, this user is created in eDirectory and the 
local user is removed. 


named DNS This system user lets DNS access local resources. 


In case of clusters, DNS data is on NSS volume, and so the user has 
to be created in eDirectory as well. 


named is used by default, but any local user can be used. 


novell nobody CIMOM This user is created by CIMOM but is not currently used. 


novixregd XTier The XTier Registry Daemon (novell-xregd) runs as this user. 


When NSS is installed on the Linux server, this user is removed from 
the local system and created as LUM-enabled user in eDirectory. This 
is required because it must have access to NSS data, and all NSS 
access is controlled through eDirectory. 


novixsrvd XTier The XTier Server Daemon (novell-xsrvd) runs as this user. 


When NSS is installed on the Linux server, this user is removed from 
the local system and created as LUM-enabled user in eDirectory. This 
is required because it must have access to NSS data, and all NSS 
access is controlled through eDirectory. 


wwwrun Apache The Apache daemon runs as this user. 


When NSS is installed on the Linux server, this user is removed from 
the local system and created as LUM-enabled user in eDirectory. This 
is required because it must have access to NSS data, and all NSS 
access is controlled through eDirectory. 


System Groups 


These are groups in the local Linux system that provide a group ID (gid) to an OES process. 


When NSS is installed, some of these groups are moved to eDirectory and LUM enabled. This is 
done to provide access to NSS data and to keep group IDs the same across multiple servers. 


Table H-2 lists the system groups that are used by OES services. 
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Table H-9 System Group Purposes 


System User or Group Associated Service Purpose 
Name 
Iprint (POSIX) iPrint The iPrint daemons use the group ID (gid) of this group 


iprintgrp (eDirectory) 


to run. 


If iPrint is moved to NSS, the iprintgrp group is created in 
eDirectory. 


ncsgroup NCS ncsclient is a member of this group. 

novell nogroup CIMOM This group is created by CIMOM but is not currently 
used. 

novixtier XTier The XTier daemons use the group id (gid) of this group to 
run. 
Apache (wwwrun) is a group member because it needs 
XTier socket access. 
When NSS is installed on the Linux server, this group is 
removed from the local system and created in eDirectory. 
This is required because members of this group must 
have access to NSS data, and all NSS access is 
controlled through eDirectory. 

server_name-W- Samba (Novell) All users granted Samba access are originally assigned 

SambaUserGroup to this group, which disables SSH access for them on the 
server. For more information, see "The Samba 
connection:" on page 93. 

WWW Apache Apache (wwwrun) and tomcat (novlwww) use the group 
ID (gid) of this group to run. 

Tomcat 


Auditing System Users 


User novlxsrvd is in the group because it needs access 
to an Apache domain socket. 


When NSS is installed on the Linux server, this group is 
removed from the local system and created in eDirectory. 
This is required because members of this group must 
have access to NSS data, and all NSS access is 
controlled through eDirectory. 


It is the nature of the Linux operating system and the POSIX security model that the root user has 
access to all system information stored on the local server. Due to this fact, some organizations 
choose to monitor the activities of privileged users. 


If you are interested in monitoring such activities, two Novell products can assist you. 


* Novell Sentinel: Universal Password events can be monitored using Novell Sentinel. You 
enable this by modifying the NMAS Login Policy Object. For instructions, see "Auditing NMAS 
Events." Then refer to the Novell Sentinel Documentation (http://www.novell.com/documentation/ 


sentinel6/) for further instructions. 
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* Privileged User Manager: This product lets you monitor root user activities on the OES server 
by collecting data, analyzing keystrokes, and creating indelible audit trails. For more information, 
see the Novell Privileged User Manager Documentation (http://www.novell.com/documentation/ 
privilegedusermanager22/index.html). 
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l.1 


l.2 


Administrative Users and Groups in 
OES 2015 SP1 


eDirectory Administrative Users and Groups 


Every OES network requires at least one administrative-level user to manage regular network users 
and system users. 


Table Il-1 Administrative Users and Groups 


Administrative User or Associated Service Object Type Purpose 
Group 
Admin eDirectory Admin User The eDirectory administrator that 


has all rights to manage the Tree. 
The default is Admin. 


Container Admin eDirectory Admin User These administrators are usually 
responsible for administering within 
a partition or subtree. 


They might be assigned only 
enough rights to install servers, or 
they might be assigned to specific 
roles in iManager. 


admingroup eDirectory Admin Group Provides LUM-enabling for the 
eDirectory administrator. 


iFolderAdmin iFolder 3 Service Admin This is the default iFolder service 
administrator account. By default, 
the Tree Admin is specified. 


TIP: The iManager Role-based-services (RBS) feature lets you delegate administrative 
responsibilities based on administrative roles. For more information, see "Role-Based Services" in the 
NetlQ® iManager Administration Guide. 


Active Directory Administrative Users and Groups 


Administrative access to NSS AD service components is controlled by the AD users and groups 
summarized in Table l-2. 
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Table 1-2 Administrative Users and Groups 


Administrative Group Associated Service Object Type 


Administrator Active Directory Admin user 


Purpose 


The Active directory administrator 
that has all rights to manage the 
Active Directory Domain 


Delegated Administrator Active Directory Admin user 


These administrators are usually 
responsible for administering within 
a specific OU. They might be 
assigned only enough rights to 
install servers or they might be 
assigned to specific roles. 


These are similar to eDirectory 
Container Administrators. 


Domain Admins NSS AD AD Group 


Members of this group in the 
domain the OES server has joined, 
have Supervisor rights on the AD- 
enabled volumes associated with 
those servers. 


A different group can be designated 
through the nitconfig utility or by 
manually editing the nitd.conf 
file. 


OESAccessGrp NSS AD AD Group 
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Members of this group have rights 
to manage trustee assignments, file 
attributes, and so forth on AD- 
enabled NSS volumes as their 
trustee assignments allow. 


If the group doesn't exist, all AD 
users with the required trustee 
assignments can perform 
management tasks on AD-enabled 
volumes. 
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J.2 


J.2.1 


Coordinating Password Policies 
Among Multiple File Services 


* Section J.1, "Overview," on page 285 
* Section J.2, "Concepts and Prerequisites,” on page 285 
¢ Section J.3, "Examples," on page 286 


* Section J.4, "Deployment Guidelines for Different Servers and Deployment Scenarios," on 
page 289 


Overview 


OES 2015 SP1 includes native file services for Windows and Macintosh workstations: 


Macintosh Workstations Windows Workstations 
* Novell AFP * Novell CIFS 
* Novell CIFS * Novell Samba 


* Domain Services for Windows (DSfW) 


DSfW is not classified as a file service, but it includes a 
customized version of Samba that is different from 
Novell Samba. 


Each of these services requires that users who access them have Password policies that meet 
specific requirements. Users can be governed by only one Password policy at a time, so if any of your 
network users require access to more than one of the file services, you need to coordinate the 
Password policies that govern the users to ensure that they can access the different file services. 


Concepts and Prerequisites 


Prerequisites for AFP, CIFS, and Samba access are explained in the following sections: 


¢ Section J.2.1, “Prerequisites for File Service Access,” on page 285 
¢ Section J.2.2, “eDirectory contexts,” on page 286 
¢ Section J.2.3, "Password Policies and Assignments,” on page 286 


Prerequisites for File Service Access 


The following are the prerequisites for user access to AFP, CIFS, and Samba services: 


* The eDirectory context under which users are searched for must be configured during service 
configuration. 


* The users need to be governed by Password policies that enable Universal Password for them. 
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J.2.2 


J.2.3 


J.3 


J.3.1 


* There must be at least one writable replica of NMAS version 3.2 or later having the user object 
trying to access the AFP or CIFS server. NMAS 3.2 is already present on OES 2 servers, and 
NMAS 3.2 is installed on servers running eDirectory 8.8.2. On NetWare servers with a lone 
writable replica of a AFP or CIFS user, NMAS should be upgraded by upgrading to the Novell 
Security Services 2.0.6 on eDirectory 8.7.3 SP10 or eDirectory 8.8.2. 


* The file access services will provide access/visibility to the users as per the trustee rights they 
have on the volumes and files. 


In addition, Samba (on both DSFW and non-DSFW servers) has the following additional 
requirements: 

* The users must be LUM-enabled on the server. 

* The users must be members of a LUM-enabled group on the server holding the volumes. 


Ħ Samba users must be created in a container or partition that has a Samba-qualified password 
policy assigned to it. 


eDirectory contexts 


* AFP: These are the contexts under which the user objects will be searched for during an 
authentication. In a name-mapped (existing tree) install, if the context resides in a DSfW domain, 
the context can be specified either in the domain name format (Active Directory format) or in the 
X.509 format. 


* CIFS: The eDirectory contexts of users can be specified either in the domain name format 
(Active Directory format) or in the X.509 format. 


* Samba: Depends on LUM to search for the user in eDirectory and therefore doesn't require an 
eDirectory context. 


Password Policies and Assignments 


* Samba: Creates a default password policy, but does not attach this policy to any user. 


* DSFW: The password policy in a DSfW environment is modeled after Active Directory Password 
policies. There is a single Password policy at the domain level, and it is configured during 
provisioning. eDirectory allows you to set policies at the user or container level. However, this is 
not recommended in a DSfW environment. 


Examples 


* Section J.3.1, "Example 1: Complex Mixed Tree with a Mix of File Access Services and Users 
from across the Tree," on page 286 


¢ Section J.3.2, "Example 2: Mutually Exclusive Users,” on page 288 


Example 1: Complex Mixed Tree with a Mix of File Access 
Services and Users from across the Tree 
* "Tree Setup" on page 287 


+ “OES/NetWare Servers" on page 287 


* "File Services" on page 287 
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* "User Access to Services" on page 288 
* "Rights Required for Installation and Administration" on page 288 


Figure J-1 Example 1 


s=widget 
idget,dc=com 


9u-prv,o-widget | ou-wal,o-widget 
yu=eng, ou=prv, o=widget IN ou-prv,o-widget 


The WIDGETS_INC tree has the following configuration: 


cn-security 


ou-blr,o-widget 
de=blr, dc=widg et 4 


ou-sales,ou-blr, o=widaat 
de=sales, dc=blr, dc=widget,4 


Tree Setup 


* o=widget, ou=blr,o=widget, and ou=sales,ou=blr,o=widget are eDir partitions as well as name 
mapped domains. 


* ou=prv, o-widget, ou=wal,o=widget, ou=hr,ou=prv,o=widget are partitions (but not domains) 


* ou=end,ou=prv,o=widget refers to the top of a subtree but not a partition. It is a container under 
the ou=prv,o=widget partition. 


OES/NetWare Servers 


+ S1-S6 and S9 are OES servers 
* S7 and S8 are NetWare servers 


File Services 


* S1, S2, S3, and S4 are DSfW servers and serve volumes over Samba and NCP 
* S5 serves its volumes over AFP and NCP 

* S6 serves its volumes over CIFS and NCP 

* S7 serves its volumes over AFP, CIFS, and NCP 

* S8 serves its volumes over NetWare CIFS, NetWare AFP, and NCP 

* S9 serves its volumes over AFP, Samba, and NCP 
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NOTE: Although Novell CIFS and Samba can both be installed on the same machine, they cannot 
run together because of a port conflict. The administrator can configure either Samba or Novell CIFS 
on a single machine, but not both. 


User Access to Services 


Users from all over the tree can access services running on S1-S9. In order for users to be able to 
access AFP/CIFS services, the search contexts (eDirectory contexts) for these services should be 
configured to the subtrees under which those users can be found. 


Rights Required for Installation and Administration 


Installation and configuration in iManager must be done by an OES administrator. This is typically a 
container administrator in eDirectory who has supervisory privileges over the container where the 
server is being installed. This need not be the tree administrator. 


J.3.2 Example 2: Mutually Exclusive Users 


288 


* "File Services” on page 288 
* "Users" on page 289 


In this scenario, the setup of the tree and file services is similar to that in Example 1, but the users are 
local to the context where a particular service is installed. 


Figure J-2 Example 2 


cn-security 


ou=blr, o=widget 
dc-blr, dc-widget/d 


gu-prv,o-widget ^ ou-walo-widget 


ou=sales, ou=blr, o-wjdagt 
dc-sales, dc-blr, dc=widget, 


File Services 


* S1, S2, S3, and S4 are DSfW servers and serve their volumes over Samba and NCP 
* S5, S6, and S7 serve their volumes over AFP and NCP 
+ S8 and S9 serves their volumes over CIFS and NCP 
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J.4 


J.4.1 


Users 


For example, u1 is a user under the container ou-prv,o-widget and is expected to access AFP 
services on S5, S6, and S7. Similarly, u2 is a user under the container ou=wal,o=widget and is 
expected to access CIFS services on S8 and S9. 


Deployment Guidelines for Different Servers and 
Deployment Scenarios 


¢ Section J.4.1, "Deployment Scenario 1: Complex Mixed Scenario with a Mix of File Access 
Services," on page 289 


* Section J.4.2, "Deployment Scenario 2: Mutually /Exclusive Users," on page 291 
* Section J.4.3, "Deployment Scenario 3: Simple deployments,” on page 291 
* Section J.4.4, "Modifying User Password Policies after Samba/DSfW Is Installed," on page 291 


* Section J.4.5, "Adding New User eDirectory Contexts to AFP/CIFS after AFP/CIFS/Samba/ 
DSfW Is Installed.," on page 291 


* Section J.4.6, "Enabling File Access for DSfW Servers Across Domains," on page 292 


Deployment Scenario 1: Complex Mixed Scenario with a Mix 
of File Access Services 


* "First Server in a New Tree (Example1)" on page 289 


+ "Subsequent Servers in a Tree (Example 1)" on page 290 


First Server in a New Tree (Example1) 


+ "Not recommended—non-name-mapped (new tree) S1 (DSfW) server” on page 289 
* "Non-DSFW Server" on page 290 


Not recommended—non-name-mapped (new tree) S1 (DSfW) server 


Installation is the same as for the Forest Root Domain (FRD). The tree is named as per domain 
naming standards. Samba is installed as part of DSFW installation. Neither AFP nor Novell CIFS can 
be installed/configured on this server because they are not compatible with the DSFW server. 


In order for users to access NSS volumes on this server through Samba, the users need to fit the 
following constraints: 
* They must be LUM-enabled 


* Cross domain access is necessary for users from outside of the DSFW domain corresponding to 
this server to access the volumes on this server. This can be achieved by adding those contexts 
to the LUM context for the LUM workstation object that represents the domain controller. 


* Winbind translates user principles to UIDs for non-NSS volumes. LUM enabling is not required 
for non-NSS volume access. 
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Non-DSFW Server 


If the first server in the tree is a non-DSFW server, then any combination of AFP, Novell CIFS, or 
Samba can be installed on this server. Because the tree is being newly created, the users, the proxy 
users (system users), and the Password policies will not be present. Use the following procedure for 
installation: 


1 Install and configure the server with eDirectory, NSS, and other core services, but without 
selecting file access services. 
2 Use auto-created common proxy user in eDirectory configuration for the OES services. 
3 Use iManager to create a system user (proxy user) to be used for the OES services. 
4 Use the Yast install to configure the Novell AFP and Novell CIFS services as follows: 
4a Use an auto-generated common proxy user for all the services. 
4b Specify the contexts under which to search for the AFP or CIFS users. 


5 If the AFP/CIFS/Samba user objects are present on NetWare servers, upgrade Novell Security 
Services version 2.0.6 in order to upgrade to NMAS 3.2 on NetWare. 


Subsequent Servers in a Tree (Example 1) 


* "S2, S3, S4" on page 290 
* “S5” on page 290 
+ "S6" on page 290 
+ "S7" on page 290 
* “S8” on page 290 
* "S9" on page 291 
S2, S3, S4 


Administrators need to decide whether these servers should be installed on a new domain or as 
additional domain controllers during capacity planning and deployment design. Follow the OES 2015 
SP1: Domain Services for Windows Administration Guide to deploy S3 and S4 in the tree. 


S5 


1 Use an auto-generated common proxy user for all the services. 


S6 


Use the same procedure as for S5. 


S7 


Use the same procedure as for S5 and S6. 


S8 


* AFP and CIFS on NetWare don't require proxy users or password policies for service access. 
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J.4.2 


J.4.3 


J.4.4 


J.4.5 


* NMAS needs to be upgraded to 3.2+, if this server hosts the only writable replica for a partition 
with AFP or CIFS users. 


* If this NetWare box is migrated to OES2015, AFP and CIFS users should be enabled for 
Universal Password by having a password policy configured. CIFS users need to log in through 
NCP (Novell Client) to synchronize their NDS passwords to the Universal Password. 


S9 


* Use the same procedure as for S5. 


* Either use a common proxy user for all the services (AFP), or allow auto-generation of the proxy 
user/password for each AFP. 


Deployment Scenario 2: Mutually /Exclusive Users 


In some trees, AFP, CIFS, and Samba might be employed, but the users are partitioned in such a way 
that each user has access to AFP, to CIFS or to Samba, but not to all of them. 


S1, S2, S3, S4 
DSfW servers with Samba. All the users are under dc=blr,dc=widgets,dc=com. 


* You can use the default Password policy provided by Domain Services for Windows for all the 
users in this subtree. 


* You can create and use a single proxy user/password under dc=blr,dc=widgets,dc=com for all 
the servers providing Samba. 


Deployment Scenario 3: Simple deployments 


Simple deployments require very little planning. 


One auto-generated common proxy user per server for all services configured on the server is a good 
choice. 


Modifying User Password Policies after Samba/DSfW Is 
Installed 


After a new password policy is assigned to a Samba or DSfW user, rerun the YaST-based 
configuration and select the new Password policies. 


Adding New User eDirectory Contexts to AFP/CIFS after 
AFP/CIFS/Sambal/DSfW Is Installed. 


If users from additional or different eDirectory contexts need to be allowed to access CIFS or AFP, 
rerun the YaST-based configuration and modify or add the required edirectory user contexts. 
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J.4.6 Enabling File Access for DSfW Servers Across Domains 


DSfW requires that users be LUM-enabled to access NSS file services through Samba. For a user to 
access a DSfW server in a different domain, the user needs to be a LUM-enabled user on the other 
server. DSfW provisioning establishes shortcut trust between domains. Users from other domains in 
the forest can access non-NSS volumes as long as they have rights on the resources. 


To achieve this, the context of the partition root for the user object should be added as a search 
context for LUM. This needs to be done in addition to the trustee rights provided to the user (or the 
user's group) as part of file system rights. 
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K Configuration and Log Files 


K.1 


Section K.1, “AFP,” on page 293 

Section K.2, “CIFS,” on page 294 

Section K.3, “Common Proxy,” on page 294 

Section K.4, “DFS,” on page 295 

Section K.5, “DHCP,” on page 295 

Section K.6, “DNS,” on page 295 

Section K.7, “Domain Services for Windows,” on page 296 
Section K.8, “Install,” on page 297 

Section K.9, “iFolder Server,” on page 298 

Section K.10, “iPrint,” on page 299 

Section K.11, “Linux User Management,” on page 300 
Section K.12, “Migration Tool,” on page 301 

Section K.13, “NetStorage,” on page 302 

Section K.14, “Novell Cluster Services,” on page 303 
Section K.15, “Novell File Access Rights Management (NFARM),” on page 303 
Section K.16, “Novell Identity Translator (NIT),” on page 303 
Section K.17, “Novell Linux Volume Manager,” on page 304 
Section K.18, “Novell Storage Services,” on page 304 
Section K.19, “Novell Samba,” on page 305 

Section K.20, “novell-ad-util,” on page 305 

Section K.21, “NCP,” on page 305 

Section K.22, “SMS,” on page 306 

Section K.23, “Vigil,” on page 307 


AFP 


Table K-1 AFP Configuration Files 


Description 


Path 


letc/opt/novell/afptcpd/afpdircxt.conf 


List of eDirectory contexts having AFP users 


/etc/opt/novell/afptcpd/afptcpd.conf 


AFP server 


/etc/opt/novell/afptcpd/afpvols.conf 


lopt/novell/afptcpd/Ism/afplinlsmconfig.txt 


List of NSS volumes to export through AFP server 


Used by installation of AFP NMAS method into 
eDirectory tree. 
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K.2 


K.3 


Table K-2 AFP Log Files 


Path 


/var/opt/novell/log/afptcp.log 


CIFS 


Table K-3 CIFS Configuration Files 


Path 


/etc/opt/novell/cifs/cifs.conf 


Description 


AFP server run-time 


Description 


CIFS server 


/etc/opt/novell/cifs/cifsctxs.conf 


List of eDirectory contexts having CIFS users 


/etc/opt/novell/cifs/cifslogrotate.conf 


Hourly rotation of CIFS log file 


/etc/opt/novell/cifs/logrotate.d/novell-cifs-hourly 


Customized hourly rotation of CIFS log file 


/opt/novell/cifs/share/nmasmthd/ntlm/config.txt 


Table K-4_ CIFS Log Files 


Path 


lvar/opt/novell/log/cifs.log 


Common Proxy 


Table K-5 Common Proxy Configuration Files 


Path 


letc/opt/novell/proxymgmt/proxy users.conf 


Table K-6 Common Proxy Log Files 


Path 


/var/opt/novell/log/proxymgmt/pxylist.txt 


Used by installation of CIFS NMAS method into 
eDirectory tree. 


Description 


CIFS server run-time 


Description 


List of proxy users on local systems whose 
password is changed automatically 


Description 


List of proxy users used by services on local 


systems. Created when /opt/novell/proxymgmt/bin/ 


retrieve_proxy_list.sh is run. 


/var/opt/novell/log/proxymgmt/pxymgmt.log 


Configuration and Log Files 
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K.5 


K.6 


DFS 


Table K-7 DFS Log Files 


Path 


/var/log/messages 


Description 


DFS Logs 


/var/opt/novell/tomcat6/logs/catalina.out 


iManager Logs 


/var/opt/novell/log/dfs/virpr.log 


DHCP 


Table K-8 DHCP Configuration Files 


Path 


/etc/dhcpd.conf 
Table K-9 DHCP Log Files 


Path 


/var/log/dhcp-ldap-startup.log 


VLDB Repair Logs 


Description 


Description 


lvar/log/dhcpd.log 


/var/log/rc.dhcpd.log 


DNS 


Table K-10 DNS Configuration Files 


Path 


/etc/opt/novell/named/named.conf 
Table K-11 DNS Log Files 


Path 


/var/opt/novell/log/named_zones. info 


DHCP server failure during startup 


Description 


configuration file loaded from e-directory 


Description 


/var/opt/novell/log/named.run 
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K.7 


Domain Services for Windows 


Table K-12 DSfW Configuration Files 


Path 


letc/krb5.conf 


Description 


kerberos configuration for DSfW. 


letc/krb5.keytab 


Kerberos related link used by samba service. 


letc/nsswitch.conf 


Configuration of Name service switch used by 
DSfW. 


/etc/ntp.conf 


ntp server Configuration for DSfW. 


letc/opt/novell/eDirectory/conf/nds.conf 


The eDirectory configuration file. 


letc/opt/novell/eDirectory/conf/ndsmodules.conf 


This file describes the modules to be loaded at 
boot-up into ndsd address space. Specific to DSfW 
it includes samspm. 


/etc/opt/novell/named/named.conf 


DNS configuration file. 


/etc/opt/novell/xad/gss/mech 


gssapi configuration information. 


/etc/opt/novell/xad/openldap/Idap.conf 


Defaults used by LDAP. 


letc/opt/novell/xad/xad.ini 


DSfW related information (domain name, Admin 
details, IP address, DNS context etc). 


letc/opt/novell/xad/xadss.conf 


Domain Services for Windows RPC server 
configuration. 


letc/resolv.conf 


Configuration of DNS client for accessing DNS 
server. 


/etc/rsyncd.conf 


Configuration file for adding directories to be 
synchronized during sysvolsync. 


/etc/smb.conf 


Samba Configuration for DSfW. 


/etc/ssh/ssh_config 


/etc/ssh/sshd_config 


Used to enable gssapi authentication during 
installation. 


Used to enable gssapi authentication during 
installation. 


letc/sysconfig/novell/xad2 oes11 


Table K-13 DSfW Log Files 


Path 


/var/log/messages 


/var/log/samba/log.nmbd 
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File containing parameters specified during YaST 
configuration of DSfW. Used by other components 
like LU 


Description 


For DSfW the keywords which are of importance 
are "xadsd", "smbd", and “winbind”. 


Logs related to nmbd process (“smbcontrol nmbd 
debug 10" can be used to set the log level to 
maximum.). 


K.8 


Path 


/var/log/samba/log.smbd 


Description 


Logs related to smbd process (“smbcontrol smbd 
debug 10” can be used to set the log level to 
maximum.). 


/var/log/samba/log.wb-<DOMAIN> 


domain specific winbindd logs. The DOMAIN refers 
to domain names which winbind is aware of. 


/var/log/samba/log.winbindd 


Logs related to winbindd process (“smbcontrol 
winbindd debug 10” can be used to set the log level 
to maximum.). 


/var/log/samba/log.winbindd-idmap 


Winbind id mapping related logs, that is SID to UID/ 
GID and vice versa. 


lvar/log/YaST2/y2log 


Logging done during YaST configuration and 
Installation of DSfW. 


/var/opt/novell/log/named.run 


DNS logs (Activated using command “rdndctrace 
10”). 


/var/opt/novell/xad/log/domaincntrl.log 


Logs related to domaincntrl tool operations. 


/var/opt/novell/xad/log/healthCheck.log 


Log of server pre-check operations done during 
Installation and Provisioning.(Replica status, DNS 
status, remote server connectivity, purger, 
removing bad address cache etc.). 


/var/opt/novell/xad/log/kdc.log 


Kerberos (xad-krb5kdc) related logs. 


/var/opt/novell/xad/log/kpasswd.log 


Kerberos password server (xad-kpasswdd) related 
logs. 


/var/opt/novell/xad/log/ndsdcinit.log 


More detailed log related to Installation and 
Provisioning of DSfW. 


/var/opt/novell/xad/log/provisioning.log 


Logging done during Provisioning phases of DSfW. 


/var/opt/novell/xad/log/sysvolsync.log 


Log about the sysvol synchronization details. 


/var/opt/novell/xad/run/rpcd.log 


Install 


Table K-14 Install Framework Configuration Files 


Path 


/etc/sysconfig/novell/afp_oes2015 


Logs related to rpcd daemon. 


Description 


/etc/sysconfig/novell/arkman_oes2015 


/etc/sysconfig/novell/cmmn_oes2015 


/etc/sysconfig/novell/edir_oes2015 


/etc/sysconfig/novell/ifidr3__ oes2015 


/etc/sysconfig/novell/iman_oes2015 


Configuration and Log Files 


297 


K.9 


Path Description 


letc/sysconfig/novell/iprnt oes2015 


letc/sysconfig/novell/Idap servers 


/etc/sysconfig/novell/lum_oes2015 


/etc/sysconfig/novell/ncpsrvr_oes2015 


/etc/sysconfig/novell/ncs_oes2015 


/etc/sysconfig/novell/netstore_oes2015 


/etc/sysconfig/novell/nss_oes2015 


/etc/sysconfig/novell/NvICifs_oes2015 


/etc/sysconfig/novell/NvIDhcp_oes2015 


/etc/sysconfig/novell/NvIDns_oes2015 


/etc/sysconfig/novell/nvisamba_oes2015 


letc/sysconfig/novell/oes-Idap 


letc/sysconfig/novell/quickfndr oes2015 


letc/sysconfig/novell/schematool 


letc/sysconfig/novell/sms oes2015 


letc/sysconfig/novell/xad oes2015 
Table K-15 Install Framework Log Files 


Path Description 


/var/opt/novell/eDirectory/log/oes_schema.log 


iFolder Server 


Table K-16 iFolder Server Configuration Files 


Path 


/opt/novell/ifolder3/bin/SimiasServerSetup.exe.config 
/opt/novell/ifolder3/bin/iFolderAdminSetup.exe.config 
/opt/novell/ifolder3/bin/iFolderWebSetup.exe.config 
/opt/novell/ifolder3/etc/novell-ifolder3.conf 
/opt/novell/ifolder3/etc/simias/Simias.config 
/opt/novell/ifolder3/etc/simias/Simias.log4net 


/opt/novell/ifolder3/etc/simias/apache/default/ifolder_admin.conf 


/opt/novell/ifolder3/etc/simias/apache/default/ifolder_webaccess.conf 
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Description 


K.10 


Path Description 


lopt/novell/ifolder3/etc/simias/apache/default/simias server.conf 
lopt/novell/ifolder3/etc/simias/apache/example.com/ifolder admin.conf 
lopt/novell/ifolder3/etc/simias/apache/example.com/ifolder webaccess.conf 
lopt/novell/ifolder3/etc/simias/apache/example.com/simias server.conf 
lopt/novell/ifolder3/etc/simias/apache/ifolder apache.conf 
lopt/novell/ifolder3/etc/simias/bill/Simias.config 
/opt/novell/ifolder3/etc/simias/bill/modules/Simias.Server.conf 
/opt/novell/ifolder3/etc/simias/defaults. config 
/opt/novell/ifolder3/lib64/simias/web/update/unix/unix-version.config 
/opt/novell/ifolder3/lib64/simias/web/update/windows/version.config 
/opt/novell/ifolder3/lib64/simias/web/update/mac/mac-version.config 
/etc/apache2/conf.d/ifolder_admin.conf 
/etc/apache2/conf.d/ifolder_web.conf 

/etc/apache2/conf.d/simias.conf 
/opt/novell/ifolder3/lib64/simias/admin/Web.config 
/opt/novell/ifolder3/lib64/simias/web/web.config 


/opt/novell/ifolder3/lib64/simias/webaccess/Web.config 
Table K-17 iFolder Server Log Files 


Path Description 


/var/opt/novell/log/oes/ifolder/adminweb.log 


IPrint 
Table K-18 iPrint Configuration Files 


Path Description 


letc/Id.so.conf.d/iprint.conf 


letc/opt/novell/httpd/conf.d/iprint g.conf iPrint configuration file for apache server 

letc/opt/novell/httpd/conf.d/iprint ssl.conf iPrint configuration file for apache server 

/etc/opt/novell/iprint/conf/idsd-template.conf iPrint Driver Store Daemon template configuration 
file 

/etc/opt/novell/iprint/conf/ipsmd-template.conf iPrint Print Manager Daemon template 


configuration file 


/var/opt/novell/iprint/htdocs/iprint.ini Configuration file for iPrint Windows Client 
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Table K-19 iPrint Log Files 


Path 


lopt/novell/iprintmgmt/lib/Logger.properties 


Description 


Logging other configurations file 
(java.util.logging.config.file). 


/var/log/apache2/ 


Contains log files for Apache activities 


/var/opt/novell/iManager/nps/WEB-INF/logs/ 
debug.html 


Debug information of iPrint plug-in for iManager 


/var/opt/novell/log/iprintngmt/IPrintManLogger0.log 


iprintman log file. 


/var/opt/novell/log/oes/iprint/idsd.log 


Contains log messages of iPrint driverstore 


/var/opt/novell/log/oes/iprint/iprint_nss_relocate.log 


Contains logs of iPrint nss relocation script. 


/var/opt/novell/log/oes/iprint/iprint_nss_relocate.log 


Contains log messages of iPrint relocation script 


/var/opt/novell/log/oes/iprint/iprintgw.log 


Contains log messages of iPrint gateway process 


/var/opt/novell/log/oes/iprint/ipsmd.log 


Contains log messages of iPrint manager 


/var/opt/novell/tomcat6/logs/catalina.out 


Log file for iManager activities 


Linux User Management 


Table K-20 LUM Configuration Files 


Path 


/etc/nam.conf 


Description 


Configuration parameters for lum. 


/etc/nsswitch.conf 


Table K-21 LUM Log Files 


Path 


/var/lib/novell-lum/nam.log 


LUM puts in 'nam' against 'passwd' and ‘group’ 
entries for the nsswitch plugin. 


Description 


Logging when LUM is configured. 


/var/log/messages 


Logging when namcd is running. This is the default 
location. It can also be configured to a different file 
by setting log-file-location in nam.conf and can 
change the level of logging by using log-level in 
nam.conf. 


lvar/log/ YaST2/y2log* 
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Migration Tool 


Table K-22 Migration Tool Configuration Files 


Path 


«project folder-/config.txt 


Table K-23 Migration Tool Log Files 


Path 


«project folder2/data.log 


Description 
The source NetWare server configuration file. This 


is used to verify nlm versions, code page and other 
details. 


Description 


The output and errors encountered during 
execution of migedir command. 


«project folder»/mignds.log 


The log file created during edirectory dib copy 


«project folder2/migndscheck.log 


The log file created for nds time sync check 


«project folder2/log/afp.log 


This stores the information about the command 
sequence and errors encountered during AFP 
migration. 


«project folder2/log/av.log 


This stores the information about the command 
sequence and errors encountered during AV 
migration. 


«project folder2/log/cifs.log 


This stores the information about the command 
sequence and errors encountered during CIFS 
migration. 


«project folder»/log/debug.log 


This is the developer debug log which stores 
information on the user inputs, outputs, command 
sequence, errors and success of the entire 
migration. 


«project folder»/log/dhcp.log 


This stores the information about the command 
sequence and errors encountered during DHCP 
migration. 


«project folder»/log/filesystem.log 


This stores the information about the command 
sequence and errors encountered during File 
System migration. 


«project folder2/log/filesystem.delete.log 


This stores list of files deleted from the target server 
because they were not available on the source 
server when performing the migration. This log file 
is updated with list of deleted files if you have 
selected the option Delete Files Not On Source in 
the File Options tab. 


«project folder2/log/filesystem.success.log 


This stores the list of all successfully migrated files 
during File System migration. 


«project folder/log/ftp.log 


This stores the information about the command 
sequence and errors encountered during FTP 
migration. 
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Path 


«project folder»/log/ifolder.log 


Description 


This stores the information about the command 
sequence and errors encountered during iFolder 
migration. 


«project folder»/log/iprint.log 


This stores the information about the command 
sequence and errors encountered during iPrint 
migration. 


«project folder2/log/migration.log 


This stores the information about the command 
sequence and errors encountered during iFolder 
migration. 


«project folder2/log/ntp.log 


This stores the information about the command 
sequence and errors encountered during NTP 
migration. 


«project folder-/log/serveridswap.log 


This stores the information about the command 
sequence, errors encountered and success states 
during identity migration. 


/var/opt/novell/log/migration/migfiles.log 


migfiles debug log 


/var/opt/novell/log/migration/mls.log 


mls debug log 


/var/opt/novell/log/migration/migmatchup.log 


migmatchup debug log 


/var/opt/novell/log/migration/maptrustees.log 


maptrustees debug log 


/var/opt/novell/log/migration/migtrustees.log 


migtrustees debug log 


/var/opt/novell/log/migration/maprights.log 


maprights debug logs 


/var/opt/novell/log/migration/migrights.log 


migrights debug log 


/var/opt/novell/log/migration/volmount.log vol 


NetStorage 


Table K-24 NetStorage Configuration Files 


Path 


/etc/opt/novell/netstorage/netstorage.conf 


mount debug log 


Description 


Apache config file 


lopt/novell/netstorage/webapp/WEB-INF/classes/ 
Settings.properties 


Config file for ssh enabling, zip encoding, mail 
configuration changes. 


lopt/novell/netstorage/webapp/WEB-INF/classes/ 
Settings *.properties 


Table K-25 NetStorage Log Files 


Path 


/var/log/messages 


Same as Settings.properties but language specific. 


Description 


Log file for NetStorage/Xtier 


/var/opt/novell/netstorage/cifsdav.log 
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Novell Cluster Services 


Table K-26 NCS Configuration Files 


Path Description 
letc/opt/novell/ncs/clstrlib.conf Cluster configuration file 
letc/opt/novell/ncs/«nodename» Cluster configuration for a specific cluster node 


Table K-27 NCS Log Files 


Path Description 


/var/log/messages Cluster event log. Events are viewable in Novell 
iManager by going to Clusters > My Clusters, select 
the cluster, then click Event Log. 


lvar/log/ YaST2/y2log Cluster Services configuration log 
/var/opt/novell/install/ncslog Cluster Services installation log 
/var/opt/novell/log/ncs/ Cluster resource runtime messages that are output 
<resource_name>.<load|unload|monitor>.out from the load, unload, or monitor scripts 
/var/opt/novell/log/ncs/repair.log Repair option messages (new in OES 2015) 


Novell File Access Rights Management (NFARM) 


This is a Windows shell extension. There is no configuration file involved. 


Table K-28 NFARM Log Files 


Path Description 


C:\Users\<Logged_in_user>\AppData\Roaming\NF All NFARM transactions log 
ARM\nfarm_all.log 


C:\Users\<Logged_in_user>\AppData\Roaming\NF NFARM error log 
ARM\nfarm_error.log 


Novell Identity Translator (NIT) 


Table K-29 NIT Configuration Files 


Path Description 


/etc/opt/novell/nit/nitd.conf NIT configuration file 
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Table K-30 NIT Log Files 


Path Description 


/var/log/messages Default path to NIT daemon log 


Can be changed through nitconfig utility 


/var/opt/novell/log/nit/nitconfig.log nitconfig utility log 


K.17 Novell Linux Volume Manager 


Table K-31 NLVM Configuration Files 


Path Description 
letc/opt/novell/nss/nlvm.conf Config file for nlvm. 
/var/run/novell-nss/nivm.lock Local lock file for nlvm. 


Table K-32 NLVM Log Files 


Path Description 

lopt/novell/nss/nlvm/ Directory for nlvm storage configuration database 
files. 

/var/opt/novell/log/nss/debug/ Directory for debug files when debug is enabled. 


K.18 Novell Storage Services 


Table K-33 NSS Configuration Files 


Path Description 
letc/opt/novell/nss/nlvm.conf NLVM configuration file 
letc/opt/novell/nss/nssstart.cfg NSS configuration file 


letc/opt/novell/nss/trustees.xml 


Table K-34 NSS Log Files 


Path Description 

/var/log/messages All Syslogs from NSS. 
/var/opt/novell/log/nss/debug/* Debug files for NLVM etc. 
/var/opt/novell/log/nss/rav/* Debug file for Rebuild and Verify. 
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Novell Samba 


Table K-35 Novell Samba Configuration Files 


Path 


letc/samba/smb.conf 
Table K-36 Novell Samba Log Files 


Path 


path: /var/log/samba/novell-samba-config.log 


novell-ad-util 


Description 


Service configuration 


Description 


Log file generated during execution of novell- 
samba-config.sh script 


Table K-37 Configuration Files Associated with novell-ad-util 


Path 


Description 


novell-ad-util doesn't have configuration files. However, when an OES 2015 or later server join an AD 
domain as required by the NSS AD integration service, the following files are updated. 


letc/krb5.conf 


The OES server's Kerberos configuration 


letc/krb5.keytab 


Table K-38 novell-ad-util Log Files 


Path 


/var/opt/novell/log/oes/novell-ad-util/novell-ad- 
util.log 


The default keytab file that contains the Service 
Principals of the OES server and the OES cluster 
resource if the server is functioning as a cluster 
node. 


Description 


/var/log/novell-ad-util/novell-ad-util.log 


NCP 


Table K-39 NCP Configuration Files 


Path 


/etc/opt/novell/ncp/ncp2nss.audit.conf 


/etc/opt/novell/ncp/ncp2nss.log.conf 


Description of Configuration File 


Rotation of ncp2nss audit log files (/var/opt/novell/ 
log/oes/ncp/ncp2nss.audit.log) 


Rotation of NCP2NSS run-time log files (/var/opt/ 
novell/log/oes/ncp/ncp2nss.log) 
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Path 


letc/opt/novell/ncp/ncpserv.audit.conf 


Description of Configuration File 


Rotation of NCP server audit log files (/var/opt/ 
novell/log/oes/ncp/ncpserv.audit.log) of NCP 
Server 


letc/opt/novell/ncp/ncpserv.log.conf 


Rotation of NCP server run-time log files (/var/opt/ 
novell/log/oes/ncp/ncpserv.log) 


letc/opt/novell/ncp2nss.conf 


NCP2NSS 


letc/opt/novell/ncpserv.conf 


Table K-40 NCP Log Files 


Path 


/var/opt/novell/log/libnrm2ncp.log 


NCP server 


Description of Log File 


Communication between NRM (Novell Remote 
Manager) and NCP Server 


/var/opt/novell/log/ncp2nss.audit.log 


NCP2NSS Audit 


/var/opt/novell/log/ncp2nss.log 


Communication between NCP server and NSS 


/var/opt/novell/log/ncpcon.err 


/var/opt/novell/log/ncpcon.log 


/var/opt/novell/log/ncpserv.audit.log 


NCP Server Audit 


/var/opt/novell/log/ncpserv.log 


SMS 


Table K-41 SMS Configuration Files 


Path 


letc/opt/novell/sms/smdrd.conf 


NCP server 


Description of Configuration File 


Configuration of SMDRD daemon 


letc/opt/novell/sms/tsafs.conf 


Table K-42 SMS Log Files 


Path 


/var/log/messages 


Configuration of TSAFS 


Description of Log File 


Default path 


/var/opt/novell/log/sms/smdrd_debug_MYPID.log 


When debug is enabled, logs for SMDRD calls 
(related to PID) 


/var/opt/novell/log/sms/tsafs_debug_MYPID.log 
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(related to PID) 
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Vigil 
Table K-43 Vigil Configuration Files 


Path 


letc/Id.so.conf.d/novell-libvigil.conf 


Description 


Path to libvigil shared object 


lusr/share/omc/svcinfo.d/novell-vigil.xml 


Table K-44 Vigil Log Files 


Path 


/var/log/audit/vlog/<clientName>/ 


Description XML for NSS auditing engine 


Description of Log File 


Log files represent the auditing data stream 
between the NSS Auditing Engine and vlog 
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Small Footprint CIM Broker (SFCB) 


* Section L.1, “Overview,” on page 309 

* Section L.2, “OES CIM Providers," on page 310 

* Section L.3, "SFCB Is Automatically Installed with OES 2015 SP1,” on page 310 

* Section L.4, "Coexistence with NRM and iManager in Earlier Releases," on page 311 
* Section L.5, “SFCB and Linux User Management (LUM)," on page 311 

* Section L.6, "Links to More Information about WBEM and SFCB,” on page 311 


Overview 


OES 2015 SP1 services are managed using Web-Based Enterprise Management (WBEM) as 
proposed by the Distributed Management Task Force (DMTF) (http://www.dmtf.org/home). 


The following information describes a few of the components proposed by the DMTF standards. 


+ Web-Based Enterprise Management (WBEM): Is a set of management and Internet standard 
technologies developed to unify the management of enterprise computing environments. WBEM 
provides the ability for the industry to deliver a well integrated set of standards-based 
management tools leveraging emerging Web technologies. The DMTF has developed a core set 
of standards that make up WBEM: 


* Adata model: the Common Information Model (CIM) standard 
* An encoding specification: CIM-XML Encoding Specification 
* Atransport mechanism: CIM Operations over HTTP 


* The Common Information Model (CIM): Is a conceptual information model for describing 
management that is not bound to a particular implementation. This allows for the interchange of 
management information between management systems and applications. This can be either 
agent-to-manager or manager-to-manager communications that provide for distributed system 
management. There are two parts to CIM: the CIM Specification and the CIM Schema. 


* The CIM Specification describes the language, naming, and meta schema. The meta 
schema is a formal definition of the model. It defines the terms used to express the model 
and their usage and semantics. The elements of the meta schema are Classes, Properties, 
and Methods. The meta schema also supports Indications and Associations as types of 
Classes, and References as types of Properties. 


* The CIM Schema provides the actual model descriptions. The CIM Schema supplies a set 
of classes with properties and associations that provide a well understood conceptual 
framework within which it is possible to organize the available information about the 
managed environment. 


* The Common Information Model Object Manager (CIMOM) is a CIM object manager or, more 
specifically, an application that manages objects according to the CIM standard. 


* CIMOM Providers: Are software that performs specific tasks within the CIMOM that are 
requested by client applications. Each provider instruments one or more aspects of the CIMOM's 
schema. 
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The packages contained in the Web-based Enterprise Management pattern in the Primary Functions 
category include a set of basic Novell providers, including some sample providers, and a base set of 


accompanying Novell schemas. 


SLES 11 provides SFCB as default CIMOM and CIM clients. OES 2015 SP1 uses these because 


they are part of the base OS. 


Package (RPM) 


novell-afp-providers 


OES CIM Providers 


Description 


Used by the Novell AFP iManager plug-in (novell-plugin-afptcpd) to 
read and edit configuration parameters in the afptcpd.conf, 
afpvols.conf and afpdirctx.conf files, and to start or stop the 
AFP server. 


novell-hms-providers 


Used by Novell Remote Manager (NRM) HMS (Health Monitoring 
Services) in conjunction with the sblim-cmpi-base providers to 
obtain data and status for CPU utilization, process count, physical 
memory, swap memory, virtual memory, and LAN collisions. 


novell-lum-providers 


Used by the Linux User Management iManager plug-in (novell- 
usermanagement-imanager-plugin) to read lum configuration from 
/etc/nam.conf and lum enabled services information from /etc/ 
pam.d 


novell-nss-admin-session-sfcb-provider 


A set of Linux Instrumentation for Enterprise (LIFE) providers that 
the Storage iManager plug-in uses to access OES storage 
subsystem through the SFCB CIMOM. The Storage plug-in is 
common to NSS and CIFS. 


novell-sms-cmpi-provider 


Reads and modifies the SMS configuration files and is also used 
for administration of NSS, CIFS, NCS, and DFS. 


The providers are compiled and located in the /opt/novell/ 
lib64/sfcb/cmpi folder. 


Novell-samba-cim 


SP1 


Used by the Samba iManager plug-in (novell-plugin-samba) to 
read and modify the Samba configuration file (smb . conf) when 
shares are created, deleted, or modified. 


SFCB Is Automatically Installed with OES 2015 


When you install any OES components that depend on WBEM, SFCB and all of its corresponding 
packages are installed with the components. 
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Coexistence with NRM and iManager in Earlier 
Releases 

The SFCB-based CIM providers in OES 2015 SP1 provide the same functionality and management 
capabilities as the WBEM-based CIM providers in earlier NetWare and OES releases. 


iManager plugins and NRM running on NetWare and OES (all versions) work seamlessly with 
services running on NetWare and OES (all versions). 


SFCB and Linux User Management (LUM) 


SFCB is automatically PAM-enabled for LUM as part of OES 2015 SP1 installation. Users not 
enabled for LUM cannot use the CIM providers to manage OES. 


Links to More Information about WBEM and SFCB 


For more information about WBEM, CIM, and SFCB, see the following: 


* “Web Based Enterprise Management” (http://www.suse.com/documentation/sles11/ 
book sle admin/data/cha wbem.html) in the SLES 11 documentation (http://www.suse.com/ 
documentation/sles11/index.html). 


+ Web-Based Enterprise Management (WBEM) standard (http://www.dmtf.org/standards/wbem) 
Web site. 


* Common Information Model (CIM) (http://www.dmtf.org/standards/cim) Web site. 
¢ Small Footprint CIM Broker (SFCB) (http://sblim.sourceforge.net/wiki/index.php/Sfcb) Web site. 
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M Documentation Updates 


This guide has been updated for the initial release of Novell Open Enterprise Server 2015 and 
includes information about new OES 2015 SP1 features and services. 
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